In my first post in this series, I shared six reasons for Enterprise Agile Adoption. In the second post, I discussed the three barriers, and in the third post, I shared some thoughts on what it takes to bring business users and IT teams together in forming cross functional teams.
In this post, I am going to continue this topic and discuss about stage gate models and two categories of stage gates, and share ideas on introducing agile practices. There are stage gates which are mandatory and firm. That is the first category. In the second category, there are stage gates which are mandatory but flexible. In both cases there are specific reviews and audits when projects move from one gate to another.
Typically, a stage gate associated with scoping, requirements sign-off and/or feasibility study in terms of exploring and shortlisting solution alternatives is a mandatory and firm gate. This is because, this triggers budget approvals and ‘Go / No-Go’ decision from senior management. This gate will remain a firm gate until organizations figure out a possible model for incremental budgeting and funding.
For example, as shown in Figure-1, Stage-1 comprises of two phases and Gate-1 is a mandatory and firm gate because involves requirements sign-off and budget approval.
Figure 1: A simple stage gate model
Do we have to follow a phased approach when we are in Stage-2? This is what I ask our partners and customers. One of the favorite and frequent responses to this question goes like this.
“Well, we do it that way. We complete ‘Architecture and Design’ phase because we have a central group of architects and designers. After this phase, our development team starts coding. When coding is done, our testing team takes over. There are technical reviews at the end of these phases. In this mode of working, how can we implement agile practices? Will agile software development work in our organization?”
I respond, “Yes. Let us discuss how we can do things differently in Stage-2 and make sure that we reach the second gate with better results”. This is when we explore the possibility of delivering working software in short iterations and considering working software as the measure of progress.
Yes. Iterative and incremental development in short iterations and practices such as continuous integration, automated unit testing and so on can be introduced in the second stage. Several IT teams understand and embrace this new way of working. This is the first step towards adopting agile in IT stage-gated environments.
Later in this discussion they ask, “How can we do user acceptance tests as part of iterations? That is what agile methods suggest. Don’t we have to consider this?”
That is a good question. When this question comes up, I politely recommend that we take one step at a time. The first step is to introduce agility in Stage-2. The second step is to go beyond that.
Including user acceptance tests in iterations requires continuous collaboration and participation of business users. We need their participation in grooming user stories. We need their participation in articulating or reviewing the user acceptance tests. And we know what it takes to bring business users and IT teams together. It is not impossible. It is going to be our second step. When we find ways to make it possible we realize that the second gate is a flexible gate.
Before I pause, let me ask you some questions. Have you been through the first step discussed in this post and implemented agile practices within your IT organization? Was that beneficial? What were the challenges? Let us discuss.
In my next post, let us discuss some interesting factors in taking this journey forward.