Agile Readiness
A key question for any organization is are you ready for Agile? And furthermore, how do you know you are ready for Agile?
Business Sponsorship
Do you have a sponsor from the business (NOT within the organization) that can be actively engaged in the development of the services or solution? This is not a full-time commitment. This is a commitment to be actively engaged in the process, to be there, to define and refine requirements, to prioritize the sprint backlog (the listing of tasks to be completed within the defined “sprint” – usually 4-6 weeks), and to be on-hand to set the objectives for each sprint.
Why is this necessary?
Pardon my answering the question with a question, but let me ask you: What do teams do in the absence of leadership? They either make their own decision or they decide not to decide and do nothing at all. Agile development does not let you off the hook for leadership. In fact, it requires a much greater sense of leadership, because ostensibly you are making decisions in a time boxed span of time.
I would say, if you cannot identify a business sponsor for the product that needs to be delivered, then the problem you need to solve within your company is bigger than what software development life cycle (SDLC) you choose. You need a business leader who will own the product. The technology team cannot own the product. Frankly, if they do, you Mr./Ms. CEO, CFO, Head of Sales will be unhappy with the results. Address any lack of business willingness to engage before you make paradigmatic changes to how you develop the product.
Change Management
I heard a story one day about Abraham Lincoln. He was asked by a newspaper reporter why he changed his mind about a key piece of legislation. He remarked “I do not think much of a man who does not know more today than he did yesterday.” The same holds true for software development. Things are going to change. Knowledge will change that could render what was thought to be a 2 hour task into a 20 hour task. Alternatively, the business environment could shift and therefore what was laid out as a sprint objective is no longer valid.
How do you handle change today?
If you have mature processes for managing change, then shifting to Agile is merely going to require a mental paradigm shift, but the essence of the process will be the same. Conversely, if your change management processes are immature, then moving to Agile will simply exacerbate that lack of maturity. You need to address your Change Management process. Let me dig a bit deeper, because I think this topic is paramount to successful product development. Here are some key questions to ask to uncover how mature your change management process is:
- Change Request Process – How does change flow into the organization? Is there a formal process for accepting the change? Does someone fill out a Change Request (CR) form or enter a ticket in your ticketing system? Or, is it a hallway discussion?
- Change Review Process – Is there a formal process for reviewing the change (determining impact to original scope, impact to current systems and impact to current processes) and providing an estimate for the impact of the CR? And, executing the change.
- Change Approval – Who must approve the change? Who must authorize the change to be accepted into the scope of the project?
If the answer to any of these question is “I don’t know” or “We just accept the change” or “No one is required to approve the change” then you likely have just uncovered why your waterfall projects suck so much. That is to say, if you are not managing these things well now, then your software development process is irrelevant to your project success rate.
Agile, by default, accepts that change happens. Assumptions can be incorrect. Requirements may have omitted key details. Requirements thought to be important can end up with a lower priority. These are natural things that will occur in any business environment and Agile is, in my opinion, the best SDLC/PMLC methodology for adjusting to these business truisms. But, be clear, Agile means quicker response to change… it does not mean chaos. It does not accept that every change disrupts an ongoing sprint. It requires that the following considerations be reviewed before accepting change:
- Sprint capacity
- Task priority
- Sprint objective
If there is no capacity for the change, then other tasks need to be de-prioritized or that CR is simply going to have to wait. If the CR goes against the sprint objectives that the business laid out, then the business needs to approve a change to the objectives or the person requesting it is going to need to convince the business sponsor of the importance of the CR.
If your environment isn’t conducive to this, then you need to change your business environment so that it is or just accept a very high failure rate for your projects. Pardon my bluntness on this matter, but this is simply how projects work. Any project or product development process can accept change. But, it cannot accept unstructured change otherwise you sacrifice the predictability of the project planning and software development process. You also sacrifice team morale, because the development process becomes chaotic, when really, it doesn’t have to be that way.
You might be inclined to retort, “But, this is going to slow down my organization.” Not necessarily. This will slow down the pace of chaos, but it will not effectively slow down how quickly your development teams can deal with change. In fact, the CR Review meeting can be a mere 15 minutes to quickly decide are we doing this or are we not? What needs to be moved out? Is the business OK with it? Excellent! LET’S GO!
Most importantly, a structured change management process sets expectations with external parties as to how they introduce change, when they can introduce change and what the process is for disrupting the development cycle to make a course correction. We seek controlled chaos.
Other Implications
It should be noted that there are some other implications to this approach. The main impact is on technical architects who may be used to a certain level of autonomy. With the business more involved in the day-to-day, this will mean that technical leadership is not free to make their own changes on the fly and as they see fit. For example, they cannot change the sprint objectives. They cannot arbitrarily change the sprint backlog or de-prioritize a task. The MUST communicate. They must enter their own CRs if need be and review them internally and externally with the business sponsor. They may not make product changes without a consensus view. A perfect segue into my next topic:
Communication
How effectively do your teams communicate with one another? Is there in-fighting? Are there total breakdowns? Do people seek to hide information. In Agile development, information by itself is not power. Shared information is power. If you have team issues, you need to fix the team issues. Agile development, like change management, is only going to bring these issues to the surface quicker; it is NOT going to make the issues go away. Agile will require teams to collaborate well together, especially on dependent tasks and with stakeholders.
These are the high hard areas to evaluate in your organization.
How ready are you for Agile?
Best,
Jonathan P. Goldstein, PMP, MBA
McKinney, Texas
