Comments on: Formality http://ntschutta.com/jat/2005/08/14/formality/ Just A Thought...on Ajax, usability, software development and anything else that catches my fancy. Fri, 05 Dec 2008 08:53:26 +0000 http://wordpress.org/?v=2.3.1 By: ntschutta.com » Blog Archive » The Importance of Change Management http://ntschutta.com/jat/2005/08/14/formality/#comment-12 ntschutta.com » Blog Archive » The Importance of Change Management Mon, 05 Sep 2005 02:19:33 +0000 http://ntschutta.com/jat/2005/08/14/formality/#comment-12 [...] Those of you that know me and have been subjected to one of my rants knows that I’m not a fan of heavyweight methodology or professional methodologists. The so called process leaders are no different than those hearty souls that maintain corporate frameworks - from time to time, they need to spend some time in the trenches or they lose all appreciation for what the grunts face day to day. So it’s in this almost antagonistic context that I pen this piece on change management. While I may not be a cheerleader for RUP anytime soon, I do have a significant appreciation for controlling the inevitable change that occurs on any project. [...] […] Those of you that know me and have been subjected to one of my rants knows that I’m not a fan of heavyweight methodology or professional methodologists. The so called process leaders are no different than those hearty souls that maintain corporate frameworks - from time to time, they need to spend some time in the trenches or they lose all appreciation for what the grunts face day to day. So it’s in this almost antagonistic context that I pen this piece on change management. While I may not be a cheerleader for RUP anytime soon, I do have a significant appreciation for controlling the inevitable change that occurs on any project. […]

]]> By: Nate http://ntschutta.com/jat/2005/08/14/formality/#comment-11 Nate Tue, 30 Aug 2005 02:47:52 +0000 http://ntschutta.com/jat/2005/08/14/formality/#comment-11 Well, I'd argue you're always better off with the best people you can find but certainly, if you have a bunch of average or below average performers, process and planning can help. Frankly, I think that's part of what *cough* we're seeing these days...and of course you can always ask yourself "why would people want to surround themselves with average?" Truth be told, coaches, managers, etc. can only do so much to improve a good team, however, there is no limit to the damage they can cause any team. The problem with using planning and process in lieu of quality people: you get what you "pay for." In other words, if you treat people like imbeciles that have to be told *exactly* what to do at all times that is exactly what you'll get. But then that's just my opinion, I could be wrong. Given the choice, I'll take high quality people over any process. Well, I’d argue you’re always better off with the best people you can find but certainly, if you have a bunch of average or below average performers, process and planning can help. Frankly, I think that’s part of what *cough* we’re seeing these days…and of course you can always ask yourself “why would people want to surround themselves with average?” Truth be told, coaches, managers, etc. can only do so much to improve a good team, however, there is no limit to the damage they can cause any team. The problem with using planning and process in lieu of quality people: you get what you “pay for.” In other words, if you treat people like imbeciles that have to be told *exactly* what to do at all times that is exactly what you’ll get. But then that’s just my opinion, I could be wrong. Given the choice, I’ll take high quality people over any process.

]]> By: jjathman http://ntschutta.com/jat/2005/08/14/formality/#comment-9 jjathman Fri, 26 Aug 2005 03:17:31 +0000 http://ntschutta.com/jat/2005/08/14/formality/#comment-9 I definitely agree with you Nate. Obviously certain managers (*cough*) think everyone is plug and play. Its easy on a high performing team to say that all this overhead/process slows people down because we are disciplined enough to manage ourselves. But what do you think about a less experienced or not as talented staff? Does the BDUF and LOTS of process work better for these types of teams? Is there a relationship between the abilities of a team and the amount of process necessary? I definitely agree with you Nate. Obviously certain managers (*cough*) think everyone is plug and play. Its easy on a high performing team to say that all this overhead/process slows people down because we are disciplined enough to manage ourselves. But what do you think about a less experienced or not as talented staff? Does the BDUF and LOTS of process work better for these types of teams? Is there a relationship between the abilities of a team and the amount of process necessary?

]]> By: Nate http://ntschutta.com/jat/2005/08/14/formality/#comment-7 Nate Wed, 24 Aug 2005 00:47:14 +0000 http://ntschutta.com/jat/2005/08/14/formality/#comment-7 John - couldn't agree more. Culture is so key (and you and I have some shared history there!) The longer I develop software, the more I realize that people are by far the most important piece of the equation. Sure, you can have the best tools, the fastest computers...if you've got average people you'll wind up with average software. I think its interesting that the people who know the least about agile call it undisciplined when in my mind, there's more structure in a well run agile project than most of the fire fights I've been on! Oh, by the way, my project has over 1400 tests - maybe that's not much but we've only got about 600 Java classes. Needless to say, I like JUnit! John - couldn’t agree more. Culture is so key (and you and I have some shared history there!) The longer I develop software, the more I realize that people are by far the most important piece of the equation. Sure, you can have the best tools, the fastest computers…if you’ve got average people you’ll wind up with average software. I think its interesting that the people who know the least about agile call it undisciplined when in my mind, there’s more structure in a well run agile project than most of the fire fights I’ve been on!

Oh, by the way, my project has over 1400 tests - maybe that’s not much but we’ve only got about 600 Java classes. Needless to say, I like JUnit!

]]> By: Gear Daddie http://ntschutta.com/jat/2005/08/14/formality/#comment-4 Gear Daddie Mon, 15 Aug 2005 14:21:03 +0000 http://ntschutta.com/jat/2005/08/14/formality/#comment-4 Good write up! "What affect does company culture have on the need for formality?" I think that has a LOT to do with the need for formality. Some companies have a real CYA culture where its more about proving you did what you were told to do rather than solving the right problem the right way. Obviously in a culture like that having tons of formality allows everyone prove they followed the "letter of the law." Regardless, its tough to be sucessful in that environment. In a culture of "trust" (IMHO) it is easier to adopt less formality. "Does the type of application matter? What’s the right level of formality?" I'm sure it matters in some cases, but I don't think its the significant factor. Instead I think it has more to do with the team and how it wants to work. Both Alistair Cockburn and The Pragmatic Programmers believe that your process (and thus the "level of formality") should taliored to individual teams/projects adopting appropriate aspects of agility. I think the hardest thing is that experts always say "it depends" leaving you to figure out the right balance. "I’m not ready to run out and champion CMMI at my employer" I hope not! ;-) "I think I might try and impose a tad more discipline." Discipline and formality are orthogonal. Most agile processes stress discipline. I think the more interesting question is: After 18 months and a merger, are your requirements still the same? Is the project's business case unchanged? If the answer is "yes" then I would say for your project... formality could be useful because you have very static requirements. If not, I'd say... get the code building, grab some high priority user stories and write tests to prove that the feature is complete/there (green bar done! ) or needs to be developed. Good write up!

“What affect does company culture have on the need for formality?” I think that has a LOT to do with the need for formality. Some companies have a real CYA culture where its more about proving you did what you were told to do rather than solving the right problem the right way. Obviously in a culture like that having tons of formality allows everyone prove they followed the “letter of the law.” Regardless, its tough to be sucessful in that environment. In a culture of “trust” (IMHO) it is easier to adopt less formality.

“Does the type of application matter? What’s the right level of formality?” I’m sure it matters in some cases, but I don’t think its the significant factor. Instead I think it has more to do with the team and how it wants to work. Both Alistair Cockburn and The Pragmatic Programmers believe that your process (and thus the “level of formality”) should taliored to individual teams/projects adopting appropriate aspects of agility. I think the hardest thing is that experts always say “it depends” leaving you to figure out the right balance.

“I’m not ready to run out and champion CMMI at my employer” I hope not! ;-)

“I think I might try and impose a tad more discipline.” Discipline and formality are orthogonal. Most agile processes stress discipline.

I think the more interesting question is: After 18 months and a merger, are your requirements still the same? Is the project’s business case unchanged? If the answer is “yes” then I would say for your project… formality could be useful because you have very static requirements.

If not, I’d say… get the code building, grab some high priority user stories and write tests to prove that the feature is complete/there (green bar done! ) or needs to be developed.

]]>