marick
Brian Marick
Member
Posts: 68
Registered: 20 Apr 07
Member Is Offline
|
![[*]](./images/grass/default_icon.gif) posted on 26 May 07 at 02:39 PM |
|
|
Front-line organization: CON
See http://forum.agilesoftwaredevelopment.org/viewthread.php?tid=220&page=1
CON arguments:
(I'll start.)
Agile, and Agile teams, cannot truly succeed unless the business changes. If the Agile Alliance really wants to help the team, it has to engage with
the business as a change agent.
|
|
|
PaulOldfield1
Member
Posts: 62
Registered: 05 Sep 06
Location: Perthshire, Scotland
Member Is Offline
|
| posted on 27 May 07 at 12:37 PM |
|
|
Change works best IMHO and IME when there's top-down and bottom-up change, at the same time and both working toward a shared vision.
I believe the effectiveness will be considerably more than twice the effectiveness of doing just top-down or just bottom-up alone.
Paul Oldfield
Capgemini, Telford UK
|
|
|
simonbaker
Simon Baker
Member
Posts: 19
Registered: 09 Sep 06
Location: London, UK
Member Is Offline
|
| posted on 27 May 07 at 12:42 PM |
|
|
See the whole, otherwise it's just a local optimisation.
|
|
|
PaulOldfield1
Member
Posts: 62
Registered: 05 Sep 06
Location: Perthshire, Scotland
Member Is Offline
|
| posted on 27 May 07 at 12:52 PM |
|
|
One of the Lean concepts is that we need to focus on the whole value stream. By splitting the Agile effort into two camps, we risk starting the
creation of silos. That doesn't mean we should not have semi-specialist teams; perhaps one looking at Leadership, one looking at Organisational
Change, one looking at "The Team". But all of these need to remain part of a coherent whole; working to a shared vision with a coherent
strategy.
Of course, there will be more than one way of achieving this coherence - I'm not sure that this is really a "CON" argument.
Paul Oldfield
Capgemini, Telford UK
|
|
|
LaurentB
Laurent Bossavit
Member
Posts: 22
Registered: 21 May 07
Member Is Offline
|
| posted on 27 May 07 at 01:35 PM |
|
|
(Is there a thread for people who sit on the fence ?)
I agree about the "whole system" view. In particular, I suspect we need to look even beyond the business itself, for instance to the system which
trains software professionals. Universities to start with - what fundamental skills required for Agile are being taught and to whom, with what success
- but also the mostly nonexistent system for ongoing training. You can't have projects succeed reliably unless you have a reliable source of
talent.
On the other hand, even an AA focused on working *for* front-line people may well end up looking at other parts of the system than where front-line
people work, and having effects there.
It seems to me that the AA's area of concern is this: "how does a software development effort create value ?" We should neither be myopically
focused on organizing the work of one constituency (programmers), but neither should we be so removed from the "software development" part of that
mission statement that we say things which are true irrespective of what the software people do. (For instance, "organizational change" is not very
close to that area of concern. It is an area that many in the Agile community have investigated, because many software projects are at the same time
org change projects, but it isn't quite core to Agile.)
|
|
|
marick
Brian Marick
Member
Posts: 68
Registered: 20 Apr 07
Member Is Offline
|
| posted on 28 May 07 at 03:03 PM |
|
|
| Quote: |
It seems to me that the AA's area of concern is this: "how does a software development effort create value ?"
|
Ooh, I like this. There's something here. Part of what's got me riled up is projects that make their members unhappy because individuals outside the
team won't let them create value. (By "value", I mean business value in the sense that a giant neural net trained to turn amounts of shareholder
money into increasing net present value would define it - which, as I've argued, is often not what individuals in the organization work to maximize.)
This allows pushing back against that, rather than the ineffectual griping and posting of Dilbert cartoons I see. But "pushing back" can take many
forms: organizational change, sweet reason, tough love, and even general mulishness.
The definition also includes the things that are (should be) the norm: learning, performing, etc.
The "PRO" case may steal the definition, though, because I think it fits better there. It treats organizational change as one tool that might
benefit the team, rather than as a good or a goal in its own right.
|
|
|
ScottL
Scott Lilly
Member
Posts: 4
Registered: 29 May 07
Location: Houston, TX
Member Is Offline
|
| posted on 29 May 07 at 07:14 AM |
|
|
I'd like to add my vote for "localized optimization = no optimization".
I'm currently on an "agile" team that has yet to deploy its first release after about 14 months of development. Everyone says that we've done a
great job. However, we haven't provided any value yet [to the end-user]. The mindset of the senior people on the product management side is still
that deployments are rare, so get everything you can into this release, since it's going to be a long time until you get another one out. Some of
the line level product people want to get new versions out every 30 days, but the way our current auditing and deployment group is set up, that's not
going to happen.
If the rest of the company is not agile/lean, it doesn't really matter if we (the development group) are.
|
|
|
LaurentB
Laurent Bossavit
Member
Posts: 22
Registered: 21 May 07
Member Is Offline
|
| posted on 29 May 07 at 09:59 AM |
|
|
Scott: what outside help do you think would be effective in helping your team create value with its software ?
|
|
|
WayneMack
Wayne Mack
Member
Posts: 26
Registered: 18 Sep 06
Location: Fairfax, VA US
Member Is Offline
|
| posted on 29 May 07 at 01:43 PM |
|
|
I would like to reinforce ScottL's point. Agility needs to be reflected across the entire company. When the remainder of the company is set up to
treat a deployment as a unique occurrence to be feared, there are going to be limits as to what the team can do to be agile.
The support that could be provided by outside help would include things like case studies on how to leverage agile development in various industries.
Production of directly sold software or software-based products would probably be the easiest sell. Salesmen always want the latest feature now.
Internal, centralized software as on web pages or mainframes might also be an easier sell. Distributed internal software which may have to go on a
large number of desktops and geographic locations is more challenging (a phased approach is required). Software contracting provides a difficult
environment because most contracts are fixed scope, at least in the contracting official's eye.
There are a lot of organizational hurdles to overcome to convince an organization to deploy software frequently. Though I still feel there is added
quality to software developed using agile techniques, there is not a lot of benefit to just saving "release ready" software in the version control
system.
|
|
|
marick
Brian Marick
Member
Posts: 68
Registered: 20 Apr 07
Member Is Offline
|
| posted on 30 May 07 at 07:12 AM |
|
|
| Quote: |
Though I still feel there is added quality to software developed using agile techniques, there is not a lot of benefit to just saving "release
ready" software in the version control system.
|
Perhaps there's not a lot of business benefit, but I feel there's a whole lot of benefit to the daily lives of the people on the team.
|
|
|
ScottL
Scott Lilly
Member
Posts: 4
Registered: 29 May 07
Location: Houston, TX
Member Is Offline
|
| posted on 01 Jun 07 at 04:46 PM |
|
|
| Quote: | Originally posted by LaurentB
Scott: what outside help do you think would be effective in helping your team create value with its software ? |
I've been trying to figure out what would help, but I keep thinking that "you can't help someone who doesn't want to help themselves".
However, case studies of large businesses that have shown revenue increase due to frequent deployments (after starting out with the smallest
application that adds value) may help. Another thing that might be useful would a documented software development life cycle that follows agile
principles, but also is audit friendly (SOX, in particular for my company). Our recent SDLC document looked very much like a waterfall plan. I was
hoping to see something with feedback loops and multiple deployments.
If I can come up with other ideas, I'll follow up here.
|
|
|
RSS Feed
