Agile for Budgeting

Agile (Scrum in particular) is a framework for Product development, not just software development. It’s been successfully used for a wide variety of products, from medical devices to ad campaigns.

Let’s consider an organizational budget as another form of product, and explore if Agile might offer some advantages as an approach. Key among Agile values are embracing change; transparency; inspect and adapt.

Annual budgets are resistant to change, by their nature. While a sizeable portion of the budget might be necessarily fixed, not all of it need be. Some good-sized chunk of the overall budget can be marked as “adaptable”, being altered at some time-boxed frequency during the year, to best meet business priorities at that point in time, by a consistently organized team. Depending upon the organization, its culture and needs, the release of this could be quarterly or more often.

The overall annual budget tends to reflect a command and control culture in most organizations, even in those perceived otherwise. The budgeting typically is one pass, and then consolidated. Instead, try multiple passes, iterating, with transparency of plans between organizational units.

The funds for each item are implicitly the metric for business value; if there are other factors, then this needs to be explicitly stated, and ranking of business value made clear, for each budget item.

If an organization is going through a significant transformation, the budget not only should reflect this, but needs to adapt to changing circumstances along that transformational journey. The environment around the organization will change, and particularly for transformations, malleability is essential for success. Adaptive means agile, not the traditional approach.

note: originally posted to LinkedIn Pulse, Nov. 2015

Agile User Stories and Application as Persona


In Agile, requirements are communicated via user stories.  Traditional user stories use the form, “As a …, I want to …, so that I can ….”.  For example, “As a first time user, I want to be able to create a user name and password, so I can securely do transactions.”   That enables functional requirements to be captured as user features, but still does not address the often critical “non functional requirements” (NFR) in an Agile framework.  NFR are items sometimes associated with infrastructure, such as capacity, scalability, reliability, availability, or security.

One approach to including NFR in an Agile context is to create user stories based upon the application itself as having a role or persona.  For example:

“As an application, I want to be able to process xxx transactions per second, to be able to handle peak monthly demand.”

“As an application, I want to be resistant to SQL injection attacks, so that my transaction integrity remains valid.”

Appropriate acceptance criteria need to be included; phrasing those can be challenging in these cases.

Extending the concept of the application persona further, it can also be used for other aspects of the application, such as user interface or user experience.  Those may fall outside the straightforward transactional features covered by more typical user stories; use it for the more qualitative ones, the fuzzier parts.  The usual guidelines still apply: make the story as granular as possible;  and to include acceptance criteria.  Acceptance criteria can be very difficult to create when one is trying to specify aspects of user experience as quality or beauty.

Taking this further still to the more general case of product development, including the difficult cases of ad campaigns or branding, the concept of the application or product as a persona remains tenable.

E.g., “As a brand, I want to be able to highlight the excitement of using our products, so that I can …..”

Cultivating the Zone

In the zone: usually we think of this state in terms of athletes, or creative artists: musicians, writers, dancers, poets.  Yet it’s not just for individuals, but for teams and groups as well; an example is the hyperproductive IT developer teams, mostly associated with XP and Agile practices.  Psychologists seem to prefer the term, “in the flow”, and that’s how you’ll find it in Wikipedia.

Think of it as an alignment of deep skills and a clear, achievable, meaningful task; a state of resonance between reality of the moment, the task to be accomplished, the skills brought to that situation, and an exceptional focus on that task.

It’s not just highly productive, or good solid work; it’s exceptional, out of the everyday mode of doing.

It’s never guaranteed; no sure recipes for entering into that state.  It cannot be forced.  But it can be encouraged and cultivated, nourished; allowed to happen.  Impediments to it identified and removed.

Some conditions probably necessary to achieve this state are:

  • The person or team is skilled in their field, perhaps deeply skilled.  A sense of mastery, pride in those skills, and some confidence in their use.
  • A bit redundant, that they have to enjoy what they’re doing.
  • The task is well defined, perceived as achievable, but challenging.
  • A high degree of focus and concentration; absorption in the task at hand.
  • This absorption can result in a feeling of being one with the task. The person becomes the work.
  • A feeling of fluidity, less difficulty than normal, performance seen notably above the usual.

How can we cultivate the conditions to help get into the Zone?  We, as individuals, as managers, team members, project managers, setting up an environment that allows this to happen:

  • Minimize distractions and encourage a sense of focus.  For some this means suitable music; for others, quiet; for some teams, something to impart energy. Perhaps a sign outside the team area, “Do not stick fingers in the cage.”
  • Make sure that tasks and goals are well defined and achievable. But don’t micro-manage.
  • Create an environment of minimal worries.  A sense of safety, isolation from threats.
  • Encourage a culture of mastery of the relevant skills, so that the basic tools are extensions of our thoughts. The thought effortlessly becomes the action towards the goal.

Don’t be concerned about rewarding this behavior: being in the zone, feeling that flow, is its own reward.

 

 

Choice is a Gift

 In traditional development methodology, tasks are assigned to the developer, usually by their manager or by the project manager.  In an Agile environment, the team is self-organizing.  Managers accustomed to hierarchical or command and control cultures find this unsettling, almost heretical. But repeated studies (e.g., Forrester) have shown Agile teams to be more productive.  Within the Agile community, one even discusses a team becoming hyper-productive, as though achieving an elevated state of awareness, transcendent.

 My assertion is that giving the developers the ability to choose is a major contributing factor in that increased productivity; furthermore, that this can be applied in non-Agile environments.

 It is not just the selection among different options that is empowering, but the detailed involvement in the decision process.  With that involvement comes a commitment of mental energy, an increased degree of being invested in the outcome.  The ability to choose is by itself a reward. 

 Effective choosing cannot be done in a vacuum.  As a manager, part of your role in giving a team the ability to choose is to make sure that they have correct information, as rich a context as possible for their decision;  where this fits within a larger view.  Your ability to communicate your vision is an essential ingredient in the outcome. 

 One must factor in the nature of the team:  how experienced they are; their knowledge of both subject and technology; their interaction with each other.  The degree of guidance you provide is part of your art as a manager. 

 Trust is key: bi-directional trust. You trust them, but they also need to feel that you have their back covered. Do you trust them enough so that YOU take responsibility for their choice?  If your boss comes asking, it’s still your responsibility.

 Choice can also inspire creativity, options as a gateway to innovation.  You believed the options were A, B or C, but once the team got actively involved in the decision process, they came up with a supersonic rainbow that did it faster, more reliably, and made the users happier.

 As a manager, it takes courage to trust your people and give them the gift of choice.  Reward them with this, do it wisely and well, and don’t be surprised if their excellence exceeds your expectations.