I have been helping a small-sized government agency (let's call it
Agency Pi) to improve its IT services. Management wanted the IT section to be more responsive to the information needs of the agency, which feeds into policy formulation which in turn helps create more intelligent decisions. That of course is the vision.
The IT section was not built for that new vision, so I was tapped to help make the transition. I decided to introduce Scrum and Agile software development methodologies to the organization. Note that we did not just introduce Scrum to the IT section, but to the whole organization. The way we introduced Scrum is a separate story in itself, so I'll leave this for another blog entry.
For this blog entry, I want to write about the benefits Agency Pi gained from this change effort. We could sum them up to the following:
1. More customer-centered development.
Scrum puts the customer (represented by the Product Owner) in the center of development. Programmers often snubs customers, treating them as clueless clients. The important change here was to convince everyone that the Product Owner (PO) should have more involvement and a strong voice in defining the product, the development timeline and the team priorities.
This is contradictory to traditional project management principles, where it's mostly the PM who decides on the schedule and priorities (in "consultation" with the customer).
2. Improved customer involvement in product development.
The IT section catered to internal customers, usually heads of departments in Agency Pi who were dissatisfied at the inflexibility of the IT staff in responding to change requests. In my observations of the organization, it became obvious that Pi had what I call managementitis.
Managementitis assumes that software developers can easily predict what the customers want and could build a solution with minimal customer collaboration. Managementitis is a flavor of delegation by abdication. That is, after giving instructions, customers can forget about the project and come back at deadline time to see the magical software that the team developed without customer involvement.
To change this mindset, we enforce the requirement that customers should assign a "full-time" product owner (PO) in the project. This PO will make important decisions that contribute to the design of the software. We also require the customers to attend the regular product reviews (we made some mistakes here, but that's for another blog) so there are no surprises.
3. Team mindset that embraces change.
A more difficult challenge was convincing the programmers to welcome changes requested by customers. The developers are used to the waterfall approach -- hammer out all the details in the design phase, get signoff, and build the software.
In my experience, this way of building software is inflexible, resulting to programmers who stop listening to customer change requests, and high customer dissatisfaction. I still see this tendency in the programmers, but when I see it resurfacing, I just repeat the message that "Let's accept the reality that our customers will always want to change a feature especially because what we're creating here is new to most of us."
4. More balanced leverage for negotiation between customers and developers.
The old mindset at Agency Pi promoted an adversarial relationship between customer and developer. For example, customers tended to demand unrealistic deadlines and then wanted programmers to commit and be accountable for the results. Sample dialogue:
Manager/customer: "I want this very important database system to support our Program Such-and-Such. I don't know what its features are yet, but I need it next week. You need to bear in mind that since we don't know its features, you should be prepared for changing requirements. But I still need it next week."
Programmer: "Uhm, okay. (Scratching head and wanting to jump out of window.)
You could see where the dialogue above would be headed (hint: "Hell."). And this often happened at Agency Pi. Using Scrum, we started advocating for more customer involvement. More customer involvement through the PO meant giving the PO more insight into the complexity of development. We made the customers see that development was about managing time, effort, cost and quality. Managing time is of course an illusion -- so we simply adjust cost, effort and quality based on the time we have. This is a key paradigm shift that customers and even developers need to understand in Scrum.
To do this, we repeated key messages like "We are now more open to change requests, but please recognize that these changes impact on time and effort" and "We will respond to that request, by adding it to the next sprint -- we assume that you want this prioritized?" or variations of these messages. Many developers hate to repeat themselves. But when you're dealing with deeply embedded organizational behavior, repetition helps.
Moreover, the Scrum approach gives the power of making product decisions back to the customer/PO. This often produces amazing results. Customers are more conscientious in making change requests and are more willing to bargain one feature for a more important change request.
5. Improved customer satisfaction.
Of course, doing all of the above have resulted to better relationships with the customers, and a better grasp of the internal development processes that are happening on the side of the programmers and on the side of customers.
There is now also more dialog happening in the development team, which by the way now includes the customer as part of its members. The programmers feel more empowered because it is clear to them that their participation in decisions is only up to the technical aspect. Issues on prioritization and scheduling are left for the PO to decide.
School for Startups stands out among the rest of them. What I like about the book:
