“There is nothing quite so useless as doing with great
efficiency, something that should not be done at all.” -- Peter F Drucker
The visioneers claim software is eating the world; but what is the software, is it just a piece of coding, and what's the purpose behind it?
Every software development project has a business purpose. It is to implement the business initiative, market needs, speedy time to market strategies, increased business value through improved stakeholder collaboration, you need to build the right thing and build it right – though the context can vary with the balance. For example, when you're innovating, you don't even know if you're building the "right" thing, so the smart thing to do is to experiment quickly and cheaply: to frame hypotheses, test them out swiftly, learn and adapt. When an experiment fails you get to write off the technical complication; but when one works out, please remember to pay it off!
The visioneers claim software is eating the world; but what is the software, is it just a piece of coding, and what's the purpose behind it? Every software development project has a business purpose. It is to implement the business initiative, market needs, speedy time to market strategies, increased business value through improved stakeholder collaboration, you need to build the right thing and build it right – though the context can vary with the balance. For example, when you're innovating, you don't even know if you're building the "right" thing, so the smart thing to do is to experiment quickly and cheaply: to frame hypotheses, test them out swiftly, learn and adapt. When an experiment fails you get to write off the technical complication; but when one works out, please remember to pay it off!
So the good first step is to ensure you know what is valuable and design your process
to deliver that value. Many Agile practitioners are unequipped to figure out
what the value or the right thing is. In most Agile shops that chore is kicked to
the side under the heading "stakeholder collaboration," An admission
that we abdicate product design and positioning strategy to stakeholders.
Stakeholders are supposed to tell us what to build and then we are supposed to
force them to prioritize. When it goes off the rails we always do the same
thing - we blame a lack of "stakeholder buy-in" for the failure. But the right attitude for a software
development team is to understand the business more and see the project from the customer
perspective as well. Agile teams pretend that stakeholders have answers
and that "collaboration" is the solution. Agile puts so much emphasis
on the process surrounding how story cards get posted to a wall, how people
work those stories, and etc. Unfortunately, as a community, you do not put enough
effort into shaping what story the product itself tells through the sum of all
those little cards. Agile products tend to be thought about and prioritized one
story at a time, and it shows.
Then, you
can cherry-pick the inefficient areas such as testing. Until
you know what is valuable, you don't know enough to say what else is
value-adding and what waste is. The number one thing that you can focus on is
testing and test automation. As much as 50% of the development and 70%
of the maintenance efforts involve testing, those who fail to capture a test
baseline and automate regressions that are used to revalidate software once
changes are made to it expend extra time and effort that they can avoid. Things
that you could do to put this recommendation into action include:
(1). Embrace agile test-first concepts to define your tests and the test cases and data needed to exercise them
(2). Develop a regression test baseline containing a set of tests developed per user scenarios to shake-down the software and verify its functionality and performance
(3). Conduct a test readiness review before qualification testing and then place your regression test baseline under change control
(4). Automate the generation of these tests so that they can be instantiated and replayed at the touch of a button
(5). Keep the baseline current
(6). Maintain a test history and use it to optimize your tests
(1). Embrace agile test-first concepts to define your tests and the test cases and data needed to exercise them
(2). Develop a regression test baseline containing a set of tests developed per user scenarios to shake-down the software and verify its functionality and performance
(3). Conduct a test readiness review before qualification testing and then place your regression test baseline under change control
(4). Automate the generation of these tests so that they can be instantiated and replayed at the touch of a button
(5). Keep the baseline current
(6). Maintain a test history and use it to optimize your tests
The
Agile community shall adapt to a modern product-centered mindset. Agile
has done an excellent job relieving constipation that was common in
software development 10-15 years ago. Agile has not done a so well job at
adapting itself to a modern product-centered (not project-centered) mindset. The Agile community must begin
embracing product-centered work, and not just by letting a UX team in
the door. You need to start doing your own ethnography, you need to know what
to do with ethnography when you have it, you need to understand how to shape a
product to maximize appeal, you need to be proactive in pushing stakeholders
toward concepts audiences will like.
The software design team must transform from being
Agilists into being "product people" as well if you want to deliver
better business value. And from doing
Agile to being agile, that is the agile mantra which helps focus on continuous improvement
to increase business value and customer satisfaction.
0 comments:
Post a Comment