The Lean-Agile Prism: Going Beyond The Agile Triangle

I. Introduction

During my last business trip an upscale long-stay business hotel asked me to make an assessment of the operations automation software system they developed in- house. One of the objectives of the hotel is to differentiate from competitors by offering its guests amazing accommodations and very efficient service. Its rooms are fabulous, with great interior design and functionality. Customer service seems to be good as far as I could tell (best way to assess that would be by staying as a guest for several days). An important factor they have been working on to offer excellent service is a high-degree of automation. To achieve that they have developed most of their software systems in-house and wired the entire building such that they can monitor and control all sorts of activity. It goes from familiar functions such as room access monitoring to access to safe boxes, detailed phone activity, Internet usage, room cleaning service, laundry, parking, lost-and-found, promotions, you name it.

The amount of work and time put into developing all of the automation systems and the level of automation achieved is impressive. As the systems manager (Let’s call him Mike in this article) proudly showed his amazing work —and I really mean his work since Mike single-handedly developed pretty much all the software— I noticed that he also expressed frustration because the hotel staff continuously called him for help. The pager would go off at any time of the day or the night. The staff would have all sorts of problems on issues that didn’t really exist because the software actually covered them. The high incidence of human error was also very frustrating to Mike. He was sure the problem resided in the level of education and the lack of familiarity with computers of most of the staff.

What are the real issues? Let’s analyze this from the project management triangles standpoint. 

II. Analyzing Triangles

The iron triangle.

Quite some time ago I started taking project management courses. At one of those courses, the instructor started talking about the iron triangle. It depicts the three main considerations for project management: Scope, Cost, and Schedule (see Figure 1). This tells us that we must determine, measure, and monitor those three if we want our projects to be successful. Conceptually you must determine the weight of two of them and allow the third one to slide as needed to accommodate those weights. Traditional projects are plan driven, save rare exceptions, and that means cost and schedule estimates drive the restrictions, which are the features.

Since my focus of attention at that time was on quality assurance I raised my hand and asked the instructor: “excuse me, where is quality?”. He made a pause and then said, “quality is implicit and in the middle of the triangle”. I wasn’t pleased with the answer because I think quality is too important to be just “implicit”. After that day I didn’t go back to finish the course.

Figure 1. The Project Management Iron Triangle

In real life, there are executives who set all three of the triangle’s considerations at the beginning of the project and don’t change them until late in the game, when the actual circumstances give them no option. Upper management tries to avoid such fluctuations because it is often considered a sign of failure, and as consequence quality is compromised too often.

Although Mike has a 2-person staff that is under-qualified, he is still a one-man show who is so busy attending all sorts of matters that the time to enhance and maintain the current code base becomes extremely difficult. The budget assigned to Mike also gives him no choice but to improvise at times and use equipment that is not the most adequate for the job, thus creating overhead. He himself manages pretty much all of the scope. His staff is used: one person to cover weekends, and the other to cover overnight; that is, they are used as maintenance folks for the odd hours.

The agile triangle (aka the inverted triangle)

With the emergence of agile came a new triangle, the agile triangle, which graphically is nothing more than the same iron triangle, only inverted upside-down (see Figure 2). This simple change brought, however, a very important consideration. It tells us that, to truly get a project done properly we must first determine the scope of our project, and allow cost and schedule to adjust accordingly. Meaning, executives should not say “we have x amount of dollars and t amount of time to get this project done”. Instead, the thinking shifted to “We have to allow adequate time and be willing to spend what is necessary to get all these features done”. That is, set the weight of the scope and handle cost / schedule to ensure all those features make it to market. Meaning, cost and schedule become the restrictions while features are the base for estimates because the driver is value (the vision) and not the plan. In practice, though, this was hard to handle. Companies are rarely flexible enough to follow it.

Cost Schedule

Figure 2. The Agile Triangle

Under this model Mike would be thrilled to have flexibility of cost and schedule based on set scope, but the thrill wouldn’t take long to vanish. His problems are of different nature. Yes, more budget would allow him to get better routers and backup mechanisms, and he would get a bit more sleep. However, the core problems between the Hotel staff and the systems would change little.

The new agile triangle.

If we think carefully about Scope, Cost, and Schedule, all of them are actually restrictions. Jim Highsmith did so and concluded that measuring project success only in terms of those restrictions might not be the most successful strategy, if at all. Highsmith proposed then a new agile triangle, as shown in Figure 3,

Figure 3. The new Agile Triangle

What this tells us is that Value, both to the customer and to the business, is the most important measure. The more value we provide to customer the more we ensure a successful product and returning customers. Furthermore, the more value we add to the business the happier we’ll make our investors. Quality is the second most important measure because customers expect the product or service they get to make their lives better in some way, and if quality is low then customers satisfaction is adversely affected. Oh, and quality should better the company employees’ lives by reducing not only defects but also increasing adaptability. Unhappy customers translate into loss of business. The Restrictions part of the triangle encompasses scope, cost, and schedule and must be handled the best possible way to allow for the value and quality set to be delivered.

Mike would say, “my systems has added lots of value since the level of automation is quite high, and the quality is also high because the code is reliable”. A missing piece that the new agile triangle helps Mike see is that value and quality focuses attention on meeting the customer’s conditions-of-satisfaction. Mike would then say, “it takes the hotel staff less time to do their job and less mistakes are made than with manual process; and by-the-way customers appreciate the speed and accuracy of the service.” This still leaves some loose ends.

III. The lean-agile prism

Mike showed me the diverse features of the software at the physical location within the hotel where they are actually used, which was the right thing to do. We started with the front desk, then other customer-related operations, and finally infrastructure. I was impressed in two opposite ways. On the one hand, there is this amazing system with broad scope and depth of operations automation. On the other hand, all the software the manager showed me looked and felt the same and extremely technical, no matter what the context was. To give you an idea, imagine you are using an IDE (Integrated Development Environment) tool to do your software development and, in addition, you are also browsing the net, using Gmail, Twittering, etc., all on separate windows (vs. tabs). Got the picture in your head? Good! Well… each of the applications Mike developed looked just the same, resulting on large stacks of windows; boring colors and fonts; poor flow of actions, very little human-error tolerance, no smooth sequence of operations, and so on. There were even moments in which Mike himself had to make pauses before going to the next step as he explained each feature’s functionality.

It was obvious that there was still some work to do on quality, and Mike admitted it. However, there was something much more important that was having a tremendous negative impact. I am referring to Design. For this specific example, the majority of the problems have to do with poor UI design. The different applications in the system should share a common UI language while at the same time allow each application to have its uniqueness to be effective within specific contexts. That way the system’s look and feel would be familiar to the entire hotel staff and at the same time be efficient within context.

Consider that you want to purchase a given application and shop around to find the best one for your needs. Your search narrows down the list of candidate applications to two of them. Once comparing them in detail you conclude that both applications have the same functionality, satisfy exactly the same set of needs, and have the same level of quality. Assuming you are not concerned about cost, which one would you buy? Very likely most of you answered something along the lines of “the one that I like best”; “the most impressive one”; or “the cool one”. This means that Design is a very important determinant for customer decision, and goes beyond just quality and value.

Deming, whose work influenced lean said that attention must be paid to systems, people, and the whole. Lean thinking tells us we must pay particular attention to delivered value to customer, both internal and external. Some may argue that design falls under the category of value. The way I see it, doing so would be similar to what the project management triangle did with quality by putting it as an implicit item in the middle of the triangle; or similar to saying that quality could also fall within value instead of having a place of its own, as suggested by Highsmith. Lean also puts a high emphasis on the human-factor (what Taiichi Ohno called autonomation and became better known as intelligent automation), only instead of the manufacturing perspective of humans controlling the flow of the automated process we apply the concept as human satisfaction as a motivation to use the product or service in addition to the value added by the functionality.

It is for that reason that I propose to give Design its deserved place by expanding the agile triangle, going 3-D to form a prism where the fourth vertex is Design (see Figure 4). I put Value at the top because I consider it the central one. The prism could be applied to products and services for any kind of industry and not only software development.

Figure 4. The lean-agile project prism

Summary

Some people go after the product they like best, even if it is more expensive than competing ones. Thus, design is more important to most users than price. Quite certainly many people like Apple products over competitors because they are very cool looking and don’t care at all paying more for them. Back in the days of the first generation iPod I purchased an mp3 player that actually had more functionality than the iPod and had a significantly lower price, as well as being smaller in size. When I showed it to people, they would see it and comment: “oh, that is nice, but I still like my iPod best!”

If Mike takes all this into account to improve his systems the end result will be a system that provides the same great functionality to the hotel staff but in a way that is easier and more appealing. The result will be more productive hotel staff and more time for him to get the hours of sleep he needs and time to increase the level of automation.

References

1. http://en.wikipedia.org/wiki/Project_triangle
2. Highsmith, Jim “Agile Project Mangement.” Addison-Wesley, 2010.