When other departments start to envy your team for the report and
execution capabilities you’re suddenly displaying, it shows how good your
software upgrade is, at least in the customer service space. We’ve talked about
this often: see, for example, The Power of Software. Upgrade envy is the best recommendation.
As information architect Dratz at ITtoolbox
relates, when upgrade envy hit one of his clients, and other
departments wanted part of the new information power, the easy response
would have been simply to sell more licenses to access the new tool.
Instead, he chose to take the thinking all the way back to the users
and their needs. He concluded that the users wanted the same capability
as the upgraded team, and even though they’d made the business case to share
access to the existing tool, it didn’t matter to them where the
additional capability came from.
“It meant they wanted the exact same data, presented the exact same way, with the same navigation through the data.
“As I was the one who had architected the entire
BI/EDW and had written almost all of the code, I knew exactly what was
involved. I then made the business case to our CIO
that I could provide that wide distribution of functionalities for 2%
of the cost of additional licenses. Believe me, that’s a 7-figure
savings.” See N-plementing an Enterprise Architecture
Agility could perhaps be described as the
ability never to be stuck in any groove that you can’t get out of in
response to new signals. The tale above shows the kind of agility in
development process that we admire. In development missions, even
though engineers prefer plans that don’t change, the team always has to
stay on its toes. Consultant James Taylor recommends two guiding
principles:
- Welcome changing requirements, even
late in or after development. Agile processes harness change for the
customer’s competitive advantage.
- Business people and developers must work together daily throughout the project. From Agile Business Rules
As Taylor points out, agility in our own development process helps us deliver increased agility to our customers.
Dovetail’s own Melissa Burpo in a post on her blog sends out a call for Agile Software Developers, which will give you a great picture of how we develop Dovetail Software products, with a nice description of an agile shop:
“We work in two-week iterations. We have a
collaborative relationship with our customers. We write tests before we
write functional code to clarify our design intentions. We keep the
build clean. We work in an environment that maximizes communication to
minimize the volume of spec documents. We build software that can
effectively respond to change”
James Taylor notes in his article cited
above the challenge that arises when a new requirement during
development is actually only a new business rule, for example from a
court ruling forcing new business requirements. Optimal practice is to
have agile business rules, adjustable in the easiest way you can devise.
More
on this from the Dovetail Software Blogs, as Gary Sherman walks us
through the simple steps of modifying a business rule to a custom
requirement. In this case, in the standard Dovetail thin-client
application, a business rule message is given a hyperlink to open the referenced case in a new window.
Agility
is everywhere. The planning process of the enterprise is looked at from
a developer’s standpoint in a thought-provoking article from enterprise
architect Nick Malik. He says that corporate leaders plan change in a
“waterfall” model, whereby they send periodic deluges from their
plateau of thinking, and bursts of command cascade down to fall upon
mission teams downstream. It makes sense to do this, he says, because
you want to unleash change slowly, in measured amounts, and allow tight
focus on the tasks as they are unveiled.
Not all of this
is optimal for agility in thinking, says Malik. “Of course, in
executive planning circles, there are many strategies that have been
suggested… not all of them are announced. Why is that?”
“For the same reason as you would have all your
requirements in a backlog, but you only release to the development team
the subset of requirements that they can accomplish in a single sprint.
Stability. The dev team appreciates the control they have by taking on
only a subset of requirements for each sprint. In return, they
demonstrate value on every sprint.” – An Agile Business Planning Model
But Malik thinks that the enterprise can do
better than this; he suggests that the business side can learn from the
IT side, and develop more agility in its own planning process.
“The real key to making this work is the Prioritized
Queue. Just as an agile model allows developers to see the most
important things that need to be done, and THEY can choose what they will deliver in a cycle or sprint, this model needs to work itself all the way up the chain.” – ibid
This is radical management theory, well
outside the jurisdiction of software developers, and more for the
analysts and consultants to espouse – but compelling nonetheless. It
remains true that agility is desired everywhere, throughout the whole
enterprise, and software is developing simply as a part of this current
sea change.
