• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Implementing Lean Software Development: cross-boundary agility?

 
blacksmith
Posts: 979
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

Do you have any suggestions regarding agility spanning
many layers of the software development organisation.

I mean, is it sensible to think of it as applicable to
all or most of the disciplines involved in software
development, or should each discipline (i.e. sub-team)
be tackled separately?

For example, what if a team has, java developers,
database experts, and report/documentation developers.

How would these specialisations cooperate in an agile
environment, or should they have their own specific
type of 'agility'?

Kind regards,

Gian
[ November 09, 2006: Message edited by: Gian Franco Casula ]
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An organization becoming lean means lean throughout, not just one function within the organization. The same goes with teams. Programmers, DBAs, technical writers, any and all of the roles and functions needed to deliver value to the stakeholders should be included.

For example, Scott Ambler has written extensively about bringing the database administrators and programmers together in a collaborative process. I haven't seen a lot written about documentation but I have seen teams successfully developing end user documentation as part of the same iterations/increments in which the programmers are building the product in question.
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Database. Agile Data: The Cultural Impedance Mismatch Between Data Professionals and Application Developers
Agile Database Techniques
Documentation. Agile Principles: Travel Light
[ November 09, 2006: Message edited by: Peer Reynders ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
I haven't seen a lot written about documentation but I have seen teams successfully developing end user documentation as part of the same iterations/increments in which the programmers are building the product in question.



I think I've referenced the article before, but here it is again: http://www.xprogramming.com/xpmag/Ferlazzo.htm
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Gian Franco Casula:
I mean, is it sensible to think of it as applicable to
all or most of the disciplines involved in software
development, or should each discipline (i.e. sub-team)
be tackled separately?



In my view, it's not only sensible, but actually *necessary*.

In fact I think it's necessary that you give up the idea that sub-teams form around disciplines. An important step to becoming Lean/Agile is forming cross-functional teams around goals instead.

For example, what if a team has, java developers,
database experts, and report/documentation developers.

How would these specialisations cooperate in an agile
environment, or should they have their own specific
type of 'agility'?



They would cooperate by closely collaborating. They would work closely together, trying to understand - and helping with - the whole picture, not only their speciality. In consquence, they would likely become what Scott Ambler calls "generalizing specialists" - team members who have a center of skill and interest, but nevertheless can perform a wide range of different tasks to help the team reach its goal.

They would, as a team, share a common set of values and principles, and regularly reflect on how to live them in their current situation.

Does that help?
 
Gian Franco
blacksmith
Posts: 979
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, thanks.

If I look around I've got the impression that there
are a lot of projects that need to build on creating
an 'agile momentum' of their own.

Here and there there are individuals with a development
style that has traces of agility and sporadically these
individuals meet, at least in the projects I'm involved
in.

There still is a lot to do.

Gian
[ November 10, 2006: Message edited by: Gian Franco Casula ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Gian Franco Casula:

There still is a lot to do.



There *always* is. That's what makes this job so interesting...
 
author
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would say that the span of the team that needs to work together is not just developers, testers, DBA's, and architects. A complete team is bigger than that. Depending on your world, it would include users, stakeholders, customers, technical writers, marketing people, operations people, support desk representatives, and so on. You're not done if you have code that pasts tests but can still crash when it is deployed. Nor are you done if you have not understood what customers really want, so you developed something that someone told you customers would like, but they were wrong. This is true even if you were told what to develop by someone whose job it was to tell you. (I know a lot of people don't agree with me on this, but in the lean world, you are supposed to eliminate waste, and that includes the waste of developing stuff that is not necessary.)

So yes, you most certainly have to cross boundaries in lean - that is the point of "Optimize the Whole".

Mary Poppendieck
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mary, just for the record: I totally agree!
 
The harder you work, the luckier you get. This tiny ad brings luck - just not good luck or bad luck.
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!