As an Executive, you do not have to understand all of the minutia of the Agile process as a software engineer does. However, you have to deeply understand the following fundamental concepts which will be extremely valuable to use, and which impinge upon your responsibility as an Executive.
Velocity and Transparency
Perhaps the most valuable concept to the Agile Executive is the concept of velocity. It is easier to understand velocity when you have performed one of the recommended workshops for this course, which illustrate the concept well.
In a nutshell, the basic unit of work in an Agile process is the user story. Your engineering team and product owner will have to work to perfect their ability to write, estimate and manage stories. But you must understand that each story gets an estimate, which is preferably NOT done in actual time, but in an abstract measure such as “story points.” The estimate is a representation of how much effort it will take to complete the story.
After each iteration, the estimates of stories which are definitely proven to be completed are summed together to create the “velocity” for that sprint.
The value in velocity is that over time it becomes a reliable predictor of the expected progress of your teams. After about three sprints, you can reliably expect a team to get approximately its average velocity done in each sprint.
This means that with properly estimated stories in an Agile process, you will never be forced to retract a promise made to your own superiors, because you will never be greatly surprised by a lack of progress on the part of your team.
Control of Priorities
User stories provide a convenient means of controlling priorities. A prioritized set of stories is called a Backlog. In general, your product owners, who are the voice of the end-users of your system, will set the specific priorities in the Backlog.
Your responsibility is not to set the priorities of the individual stories, but to make sure that the Backlog is the guiding force for your teams. You should periodically ask to see the Backlog, make sure it is being kept up-to-date, and ensure it is actively being used as the guide for your engineering team.
These methods provide you, the Executive, with something precious: transparency and control. It prevents the embarrassment of learning at the last minute that a software project is behind schedule. Imagine having no more missed deadlines and no more catastrophic failures.
This is not an inflated exaggeration — Agile methods really prevent drastic negative surprises. They do not, however, mean that software will be produced faultlessly at any rate you desire. Rather, they give you perfect transparency into the actual state of your project on a continual basis. You may well be disappointed by the rate at which your team produces software, but you will never be surprised, because each iteration you will have an honest measure of your actual progress or lack of progress.
Building an Agile Organization
As the leader, you must drive toward the true goals of your organization. That is, you must ensure that if you successfully build the software you are planning, it will actually meet your strategic objectives. The best way to do this is to ensure that the end-user is “in the room” with the product owner and the engineering team. Sometimes this is physically true: you should facilitate actual meetings, organized around the testing and demonstration of the software. But it must always be metaphorically true: the end-user must always be involved and available to the Engineering team.
You must also encourage and defend investments in learning for your organization. It is all too easy to demand progress at all costs from your team — but this is penny wise and pound foolish. As the Executive, it is your job to set the tone and principle that all members of your organization must be constantly learning.
Finally, you must build an organization that eschews all deception. Too often in government there is a learned attitude that you must ask for more than is really needed in order to get what you want. Rather, set the precedent of complete transparency and honesty.
To be a good Executive, you do not have to be a programmer, but you must spend some small fraction of your time with your programmers. You must establish personal communication with your engineers, and make it clear that any may speak to you freely.
By spending a small amount of time with your engineering team, you will earn their respect and avoid the catastrophe of having your team fail to be perfectly honest with you. You may be afraid of looking stupid in front of programmers, but do not let that deter you. Your programmers will respect you much more if you communicate without arrogance to them than if you do not communicate with them or pretend to know more than you do.
We recommend that you spend 75% of your time with your subordinates. You will naturally spend more time with your direct reports than with their reports. However, be sure to spend a small amount of time with each person who reports up to you, no matter through how many channels. If you manage a very large number of people, you may only spend a few minutes with each person each year, but the principle holds true. You can not lead effectively if you do not understand what the people in your organization, at all levels, are thinking.
Many people believe that if software is incomplete, it is useless. This is the way engineers think about problems. A bridge which falls down is useless. A bridge which does not span the chasm is useless. There is never a baby bridge that has a useful existence on its own.
But we have learned that software can be developed in a way that allows it to grow slowly through the accretion of individual units of functionality. You don’t need all of the units to be known before you begin work.
Sometimes you hear people say, “Change is expensive, so we should cover all our bases and be sure we do the job thoroughly the first time.” However, experience has shown the opposite is true — that if you accept and embrace change, you will actually go faster and with much lower risk.
Embracing Change in Real Life: Collin County’s Story
In Collin County, Texas, the Public Information Officer (PIO) worked with the IT AppDev team to update our Case Look-Up, Active Warrants and In-Jail applications last year. These three apps represent 65% of traffic on our website. Our goal was to responsively design all three apps so that they would look good on smartphones and tablets. During a sprint review session, one of our team suggested that ‘it would be neat’ if we could link the Active Warrants app to the In-Jail app so that law enforcement would not have to serve a warrant to an empty domicile. The PIO responded, ‘Can you do that?!” The Dev team said sure, they could link all three apps together. As a result, we dedicated one additional sprint to build the Judicial Online Search that consolidated all three previously independent apps into one. We experienced a requirement change in the middle of the development of the three different apps — and ended up making a better single solution.
Tim Nolan, Senior Applications Manager, Collin County