• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What do you mean by discipline?

 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is a nother somewhat popular book out there combining the concepts of Agility and Discipline in its title: "Balancing Agility And Discipline". As far as I know (haven't read it yet), what the authors of that book actually mean by discipline inside the book the call "plan-driven" approaches.

Personally, I don't see Agility and Discipline as being in conflict at all. Quite to the contrary, I think that there is quite an amount of discipline involved in delivering a working, fully tested system to the customer every couple of iterations; in writing tests first, in having daily standup meetings and iteration retrospectives, in keeping the code clean etc. pp.

So my question is, what is your take on Agility and Discipline? How do they connect to each other in your view? And what does the book title actually want to tell me?
 
author
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Iija,

Early in the book, we paint a process map with two axis:
=> x-axis goes from low-ceremony process (few artifacts, limited documentation, no traceability) to the left to high-ceremony processes (Change Control Boards, a lot of documentation, maintain traceability) to the right
=> y-axis goes from very short iterations at bottom, to waterfall at top

So, what is agile? Agile means (parahrasing Craig Larman) that you are able to react rapidly to change. Changing fast is typically easier if you have shorter iteration and if you have a lower-ceremony process, so you in general want to be on the lower left on the process map. But, I do not want somebody to build a pacemaker that use a low-ceremony process. I do want to have a CCB that has to evaluate and approve late architectural changes, I want to ensure that the process used is FDA compliant, etc. So, can you not be agile and build a Pacemaker? Sure, but you would need to move to the right on the process map relative to a team not building a safety-critical system. So, we use the process map to discuss what style of development you should aim at doing, and to discuss how various practices at various levels move you on the process map.

Regarding discipline - in general, we equate disicpline with high-ceremony in the process map, as described above. You can argue whether that is a good choice of word, because you can be disciplined while using a low-ceremony process. And we e.g. point out that XP is a very disciplined, low-ceremony process... So, the more precise word we use in most discussions in the book are ceremony. However, discipline is a more loaded word that we felt gave a more intriguing title.

The point with the title is that you sometimes need to make a trade-off between ceremony and agility, but it is not either or. More ceremony (discipline) may be the right for you, but it may make it a little harder for you to be as agile (reacting fast to changes) as you would like.

Cheers

/Per
 
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another book I read recently gave cred to waterfallish methodologies for the same reasons - criticality. Pacemakers, nuclear bombs, or whatever other devices that would kill someone if it has a bug.

Unfortunately, I think that the relationship then becomes "Waterfall is better when software is very important" and most every stakeholder thinks his or her project is extremely important.

I think it really comes down to whether you can make a flawless requirements document that overlooks nothing. For most any software application, particularly one with a rich UI or one that does more than babysit a database, requirements are near impossible to perfect up front.

Ok, that was a tangent.

Ceremony, I agree, is the better word but Discipline would certainly market better in the title. Agile lacking discipline is a common misperception. Ceremony is more or less a forced... er, guidance for discipline.

Examples: Scheduling meetings forces the team to get together and talk about the project. Requiring a multitude of documents forces the team to communicate and gives the nervous project sponsors "proof" that the team is making progress.

Agile methodologies have far more efficient (and fun) ways of achieving the same goals, but you do need people on your team that know what they're doing and don't require the hand-holding that ceremony provides.
 
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Per Kroll:
Regarding discipline - in general, we equate disicpline with high-ceremony in the process map, as described above. You can argue whether that is a good choice of word, because you can be disciplined while using a low-ceremony process. And we e.g. point out that XP is a very disciplined, low-ceremony process... So, the more precise word we use in most discussions in the book are ceremony. However, discipline is a more loaded word that we felt gave a more intriguing title.


Hi,

I feel that many companies use high ceremony to "force" a Discipline on their workers. A forced Discipline (noun) means that the worker does not have to think about what they are doing, they just follow the high ceremony practices that have been laid out. This means that the worker is in fact less disciplined (verb / personal attribute).

The power of Agile processes is that they are people-focussed, which empowers the workers and allows them to make decisions. Without the fall back of high ceremony 'Disciplines' the Agile worker needs to be more disciplined in applying the Agile practices, e.g. ensure they write unit tests, attend the daily stand up meeting, etc. This may be the crux of Agile processes - ensuring that everyone is motivated enough to apply themselves to all aspects of the task at hand (be disciplined).

High ceremony processes on the other hand tend to treat people like cogs in the machine - If you do it "by the book" it will work. This fails to respect people and their abilities and can lead to an attitude of 'It does not matter if it works or not, as long as I did my piece by the book / followed the prescribed steps exactly'.

To me discipline (verb) as a personal quality is much more highly valued in Agile processes than a Discipline (noun).

Hope this makes sense,

Fintan
[ September 27, 2006: Message edited by: Fintan Conway ]
 
Per Kroll
author
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Marc, you can build very complex, safety-critical systems using an iterative approach, and in fact, you can do it much more effectvely and with higher quality than if you use waterfall development! We do NOT say that you should use waterfall because you build safety-critical systems, but we say that you need a higher-ceremony process, with more checks and balances. Because you add more ceremony, you maybe also need to slightly increase iteration length, let's say from 4 weeks to 6 weeks, but you should not do waterfall development... Note that first writings on iterative development were published in IBM Systems Journal in the 70s, stating that you need to use iterative development for large complex projects. This was written in the context of NASA projects, I think...

Marc and Fintan, you both raise a valid concern, will a high-ceremony process lead to less people value, where team members are just cogs in a machinery, and if they follow the detailed process descriptions everything will turn out well?

I do not think there needs to be a link between high ceremony and de-humanizing software development. The problem with processes in the 80s and early 90s were that they tried to provide in-depth prescriptive guidance for everything. "This process will allow a moron to produce good software". We know that has failed. However, you can have high-ceremony processes that still encourage meaningful collaboration, rely on people to solve problems by working with others, leverage self-managed team. Let me give an example, you may say that in the second half of the project, you need to have all API changes approved by an Architecture Review Board. That is high ceremony, but does not prevent you from e.g. having self-managed teams. It just means that you need to motivate why you need to change the API. And if you have a good reason, the process will ensure that the change is appropriately communicated.

So, I think we need to be careful with equating high-ceremony with de-humanizing software development. It is seeing process as a detailed prescriptive 'machine code for developers" that is de-humanizing, not the high-ceremnoy as such.

My 2 cents. Cheers

/Per
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Have you heard about PatientKeeper? As far as I know, they deliver life-critical software to an increasing number of hospitals - with a deployment cycle of a couple of weeks!
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Marc Peabody:
Another book I read recently gave cred to waterfallish methodologies for the same reasons - criticality. Pacemakers, nuclear bombs, or whatever other devices that would kill someone if it has a bug.



What Waterfall basically does is deferring the most valuable feedback - that from the running system. I'm not convinced that that's a good strategy for critical projects...

I think it really comes down to whether you can make a flawless requirements document that overlooks nothing.



And have everyone *understand* it perfectly and consistently - and not make errors while transitioning to other intermediary artifacts.

Scheduling meetings forces the team to get together and talk about the project.



Yeah, but talking doesn't necessarily leas to true communication. Putting the whole team in a room and leading it to self-organize probably does...


Requiring a multitude of documents forces the team to communicate



Only if the documents are actually read - and even then that's just a very weak, low bandwith form of communication.

gives the nervous project sponsors "proof" that the team is making progress.



I guess you have a good reason for putting "proof" into quotes...

Agile methodologies have far more efficient (and fun) ways of achieving the same goals, but you do need people on your team that know what they're doing and don't require the hand-holding that ceremony provides.



I'm always stumped by suggestions that ceremony somehow can make up for missing competence. I don't see how that can be true at a meaningful scale.
 
Per Kroll
author
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Iija,

I kind of lost the thread wrt whether you commented on my posting or ealrier postings in the thread, but I agree with all your comments except one. I actually do think that ceremony is a good thing for safety critical and complex projects. Note that safety critical project SHOULD do iterative and agile development, for all the reasons you point out, but still, the more safety-critical, the more need for some kind of ceremony. Some examples from development within eclipse projects, since I am project lead for one of the elcipse projects, Eclipse Process Framework (see www.eclipse.org/epf), which I think examplifies very good agile development approaches, including iterative, continuous integration, feedback, test-driven development, users part of the dev team, ...:
- If you do an API change in the platform project, you need to go through some additional rigor. This is to avoid inappropriate API changes, or API changes that are not properly communicated. An API change can impact 100s of applications leveraging the elcipse platform... so you want to take API seriously
- For each contributions, you need to document who was the committer accepting the contribution. The resulting project log needs to be reviewed by elcipse legal. This is to avoid IP issues which could result in costly lawsuits. <Tools and procedures are in place to make this reasonably painless, but this is defintly an example of ceremony added to reduce risk for bad things to happen>
- Each committer needs to be voted in by existing committers, and approved by a committee. As a project leader, I have to provide evidence that the committer qualifies. This is ceremony added to ensure high quality committers. Asa proj lead, I should not be able to say "This person is good, I make him / her committer". Each person needs to proof their competency to become a committer...

So, these are all examples of useful ceremony aiming at making it more likely that eclipse projects build high-quality products you can trust. Eclipse development is very agile, but does have more ceremony than I have used in many other places.

There are naturally also many BAD examples of ceremony that adds no or limited value...

My 2 cents

/Per
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Per Kroll:
I actually do think that ceremony is a good thing for safety critical and complex projects.



I'm not sure I disagree. In fact, I would be surprised if PatientKeeper wouldn't use more ceremony than the average Agile project.

It just seems to me that ceremony doesn't need to have a big impact on iteration length. And it *certainly* doesn't have to imply Waterfall, as we seem to agree.

(BTW, my previous reply was to Marc, as the very first quote indicated.)
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

... will a high-ceremony process lead to less people value, where team members are just cogs in a machinery, and if they follow the detailed process descriptions everything will turn out well?



Just a report from the field ... that's often how ever increasing ceremony is felt in the rank and file. I think it would take a lot of care and effort from management that knows how to connect with their people to avoid that side effect.
 
Marc Peabody
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Per Kroll:
"This process will allow a moron to produce good software". We know that has failed.


I love it.
People are more important than any process. -Booch
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic