|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 23
Messages: 23
Messages: 23
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Some value statements beyond Agile Manifesto
Agile software development has its own manifesto which lays out the values and principles of agile process. Lets try to look beyond (or may be just deeper into the meaning of) the essential four value statements.
Self Organizing Team over Control & Command Team.
Responsibility to deliver lies with the team and not with a centralized manager who is calling all the shots with a team of resources to control and command. The team has the power to commit and it collectively strives, brainstorms, and works to meet the commitment.
Team is cross functional and have no fixed roles. It self organizes to fill in any role or responsibility and work around any strength or weakness to get the job done.
Jeremy D Miller has some very valid points to support
People in a self-organized team are able to make decisions themselves and accordingly adapt to changing situations. Command and control grunts have to wait for the boss to tell them what to do
Agile done over just done.
In agile development, when we say a feature is done, we should really mean “DONE”. When a piece of functionality is picked up from the backlog and developed as part of a sprint, it might very well be a working code and implements the intended requirement, but is it really done?.
Kelly Waters does provide an answer
In agile development, make sure that each feature is fully developed, tested, styled, and accepted by the product owner before counting it as "DONE!". And if there's any doubt about what activities should or shouldn't be completed within the Sprint for each feature, "DONE!" should mean shippable.
Michael Nygard comes with a new definition of done where he comes up with a checklist of dozen points for a feature to satisfy before it can be termed as DONE.
Enough Design over big up-front design.
In agile world we know big up-front design is not the way to go before we get down to implementation. As defined by Armon Rotem-Gal-Oz, may be just enough design up front will do.
Agilists tend to down play traditionalists reliance on Big Design Up Front (BDUF) and they are right. More often than not, Big Designs without underlying code that demonstrate it actually works and integrates well prove to be a waste of time.
Steve McConnell thinks there is definitely a shift
In ten years the pendulum has swung from “design everything” to “design nothing”. But the alternative to BDUF isn’t no design up front, it’s a Little Design Up Front (LDUF) or Enough Design Up Front — ENUF
Code Reuse over cut and paste.
Never repeat yourself, do it once and keep using the effort again and again. Do it by reference and not by value. Code should be designed in a way to enable it to be reused rather then mere cut and paste. Cut and paste in no way is an example of code reuse it is just a way to invite maintenance nightmare.
Dale beermann puts it right
The problem is that code reuse doesn’t just happen naturally. Reuse must be a core element of the design to be made possible.
Code reuse becomes much more relevant when we talk in terms of code reuse in test cases. Roy Osherove's idea.
If we don't all realize that in the real world tests have to be as maintainable (or even more so) as production code, we won't come out of the middle ages of unit testing.
Pair programming over code review
There has been a lot of debate over the applicability and feasibility of programming in pairs and does it really improve the quality of the code. A person who has done it knows it is really true. Not only there is a very good chance that the code is much better quality wise with far less numbers of bugs or hacks but it goes a long way in keeping the communication of ideas and design decision going within the team.
Jeff Atwood at coding horror has some good comparison points on pair programming over code reviews
The advantage of pair programming is its gripping immediacy: it is impossible to ignore the reviewer when he or she is sitting right next to you.
but concludes
In the end, I don't think it's a matter of picking one over the other so much as ensuring you have more than one pair of eyes looking at the code you've written, however you choose to do it. When your code is reviewed by another human being -- whether that person is sitting right next to you, or thousands of miles away -- you will produce better software. That I can guarantee
Stand up Meetings over status meetings
The idea is to keep the meeting very short that is the reason everyone stands but it is much more then communicating the status. The purpose is to show the commitment to the team and to the project, communicate the current status, plans and progress to the team rather then the manager, identify the impediments and keep the focus for the ultimate goal.
This is how it is described by Mountain Goat Software
The daily scrum is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other
|
|
|
Message #245412
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
sounds like a scheme to me
i kinda lost trust in the good faith or good will of most ppl behing agile methods, and the new methodologies in general
they say too much to fill more books to sell, and most of them don't code (at least i don't any famous opensource project major talent who is into this methodology thing)
all of what they say can be summarized in few words.
1. learn your tools/fremawork/languages well, that way u will be educated hence (i hope) competant to do what they as u
2. dont be lazy, work hard, dont spend too much time chating or listening to mp3z or whatever
3. be brave face and solve the real problems, dont be afraid of coworkers or ur manager, say it as it is, and deal with it
really this all, anything more, and ur selling me a scheme!!!
most projects that fail, fail because of who the programmers are (incompetant, lazy, coward), not because of what method they use!!!!
|
|
|
Message #245427
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: sounds like a scheme to me
Ali, please, if you want anyone to take your opinions seriously, try writing them in actual sentences.
I am just astounded when I see the readership of a website catering to professionals think it is acceptable to write comments in the same syntax they use texting their friends.
Find the <shift> key. You are not an lolCat.
|
|
|
Message #245437
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Grammar optional
Ali, please, if you want anyone to take your opinions seriously, try writing them in actual sentences.
I am just astounded when I see the readership of a website catering to professionals think it is acceptable to write comments in the same syntax they use texting their friends.
Find the <shift> key. You are not an lolCat.
While I disagree with pretty much everything Ali wrote I couldn't care less whether he wrote it in grammatically correct English or pigeon. What matters to me is that he conveyed his message clearly, and that his comments was relevant to the topic in question
|
|
|
Message #245439
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Interesting points
- Self organizing teams
In my experience, such a thing does not exist. No team that exceeds the magic number "3" (code re-use, no magic number please!) will cease to be self organizing or will spend most of its time self organizing. And this is in the good case where people have no grunts against each other and there is no external "someone has to take the blame" pressure on the team. Also, noone can be a Jack-of-all-trades, so a team just can not "work around any obstacle" if the team does not contain the required expertise, product knowledge etc. In day-to-day work, priorization issues are sure to arise as well. They will not dissolve automatically. Teams may not need "command and control", but they need leadership and decision making. Some excellent programmers are very bad in deciding anything....
|
|
|
Message #245447
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Interesting points
- Self organizing teams
In my experience, such a thing does not exist. No team that exceeds the magic number "3" (code re-use, no magic number please!) will cease to be self organizing or will spend most of its time self organizing. And this is in the good case where people have no grunts against each other and there is no external "someone has to take the blame" pressure on the team.
What I have seen happen when there is no clear leadership is that often one person will attempt to make themselves the leader by bullying others.
The problem is that this person may not really be the best leader, just the biggest asshole.
I think Agile is a reaction to the "process over results" approach that has become so popular. And in a lot of ways this is good. However, I think that this movement has made the classic mistake of letting the pendulum swing too far in the other direction instead of trying to seek the sweet-spot of 'just enough' management.
|
|
|
Message #245448
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The brilliance of Agile
Agile is probably the single best consulting business model ever created. Whether or not it produces software that's of superior quality or not is beside the point. It lets you go to a client, and sell them a never ending project and absolve yourself of any failures.
Pure Agile (with a capital A) methodology is essentially made so that no one will ever follow it exactly. Let's write all of our requirements in the form of "stories" on index cards and tape them to the wall. Ahh-now I see why so many previous projects failed, no index cards! Then, let's assign two programmers to every coding assignment rather than one. Somehow doubling the cost of development leads to a total cost savings. It doesn't take long before you realize that pair programming is a waste of time and money, and that having stories on index cards adds no real value other than making it look like you're doing stuff. And that's the beauty of the whole thing. It's made so that no one WILL EVER FOLLOW IT EXACTLY! So when a project fails, well, it's just because the project didn't follow the methodology, and Agile consultants are absolved of any responsibility (we TRIED to tell you to follow the methodology!)
Not only do you never have to accept responsibility for any failures, but as requirements change you just keep tacking on more iterations. You can stretch a 6 month project out for a couple of years if you play your cards right. What was once a nice payday has turned into a steady cash cow.
That's the real beauty of Agile, it's more profitable and failures are never your fault. Sign me up!
|
|
|
Message #245456
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The brilliance of Agile
In my opinion Agile does not restrict anyone from following all the standard process of documentation. Documents/ artifacts can be one of the deliverables. The key focus with Agile is early user feedback and also helps better tracking of the project to avoid mistakes and helps change the direction at an early stage as detected. Another key focus is re-prioritizing the backlog based on the business value for the user. The traditional model (Waterfall) is good but has some rigidness of steps and does not allow fallback.
In my Organization we have been following SCRUM for around a year now and it is a mix of both. It has been working pretty well for us. The team will commit to the deliverables for each sprint cycle. The time estimation for each task is collectively decided by the team and the estimation gets better and better in each sprint.
Here's how we do it:
1. Prioritize product backlog
2. Sprint Planning
3. Finalize goals & deliverables
4. Task break down
5. Sprint Review
6. Sprint Retrospective
There is always a SRCUM Master & Product Owner who are the facilitator and will track the project for its goals and deliverables. They do not make decisions but can always suggest, the team finally decides the direction.
There are some decisions that the team alone do not make; like selecting the stack, software, hardware etc. It will always have the management involvement. There is a member from architecture team for guidence as a shared resource. There are members from other departments / streams who are commited / shared resources in the project.
The only thing I get confused by is the definition of Cross Functional Team : It is said that everyone should do everything when needed to achieve the goal; Here my opinion is that it should be a team consisting of members with different skillsets rather than everyone should do everything when needed. I being a developer do not wish to write requirements / test cases (these are not unit test cases) / do load testing / performance testing. I am sure this will be a bottleneck in the timeline and may not be the right representation of a Cross Functional Team.
|
|
|
Message #245497
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Some value statements beyond Agile Manifesto
Of the problems is that books on Agile methodology and Agile evangelists to a certain extend portray Agile methodology as the silver bullet. But in reality is that it is just yet another development methodology. I personally have seen it succeed only on non mission critical projects where:
1) The product manager only have a vague idea of what is really required and are overexcited to change the requirements as it is being developed. (usually a website as opposed to a web-application)
2) The teams consists of a bunch of cowboy “developers”, who only know how to code. (Note the usage “developers” which is different that “software engineer”.
3) People don’t like to be organized and they cover it up under the umbrella of “Agile” (And since teams on those project as small they try to get away with it)
Yes I agree that projects need to be constantly steered and controlled, but this is not specific only to Agile!!
|
|
|
Message #245527
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The brilliance of Agile
I have used limited portions of Agile methodologies however adopting the entire process is a tough sell. With no overriding project plan and requirements which change with each iteration how do you estimate the total cost for the project? Try selling a client on the statement "we're not exactly sure how many iterations this will take but we're sure it will cost you less than a waterfall approach... and no we won't give you a fixed bid or delivery date commitment."
As for the feature backlog. How many times have you sat in a meeting with project stakeholders who classify every single feature, defect or issue as critical. I'd love to meet a product management team who can distinguish between critical, high, medium, and low without me renaming them as "end of the world", "show stopper", "must be fixed ASAP", and "critical".
On the topic of SCRUM I do have to give credit to the concept of the Sprint Plan. I've found it highly effective method of predicting and tracking the project's progress along with curbing "Student Syndrome".
|
|
|
Message #245537
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The brilliance of Agile
Steve Yegge had a good post about what he calls good agile vs. bad agile. You can read it here if you're interested:
http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
I think what's worth pointing out in that blog is that the "good Agile" written about at Google is very notable for how much respect it places on developers and how empowered everyone is.
I haven't read all the Agile books out there, but I do know that the "Lean Software Development" series is pretty adamant that nothing that claims to be "Agile" is worth anything if the people doing the work don't feel respected or empowered (I know "empowered" is business-speak, but I'm currently at a lack for a better word). It sounds like that the concepts in that book would mesh very well with what Google is doing.
Also, it would seem to me that the term "Agile" is naturally failing to hold its meaning as more and more people talk about it. Just like "SOA". Maybe even "object oriented". "Domain driven design" might be the next one to fall as it becomes more popular, and people start using it to mean different things.
I do think this is a case where it's important to distinguish principles from practices. Pair-programming is a practice. I've always thought that it sounds pretty lousy. But the principles behind it make a lot of sense. I think those principles could fall into the "Agile" bucket, whereas I would not see those principles being in the "Cowboy" bucket, for example. So there's plenty to bash about practices that Agilists recommend, just like there's plenty to bash about Waterfall and Cowboy practices. What's more worthwhile is to look at the principles they're trying to achieve. Though that's not nearly as enjoyable as just making fun of what people are doing. =)
|
|
|
Message #245553
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Interesting points
What I have seen happen when there is no clear leadership is that often one person will attempt to make themselves the leader by bullying others.
As opposed to saying pretty please will you all work together?
Yeah. THAT works.
How would you suggest moving a stuck team forward?
I think if I wear a cheerleader skirt I'll get fired.
But seriously, more often than not a team contains a least a couple members who will fight against any sort of progress. Sometimes these people are directly opposed to the project. Sometimes they simply fear the project leaving the domain that they understand...especially when their domain is making pretty powerpoint slides. Either way they work to keep the project stuck.
Someone needs to make them move.
|
|
|
Message #245589
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Interesting points
What I have seen happen when there is no clear leadership is that often one person will attempt to make themselves the leader by bullying others.
As opposed to saying pretty please will you all work together?
No, opposed to having clear roles and leadership responsibilities. The idea that a project can be run by a bunch of people all 'doing the right' things smacks of the fallacy of communism, IMO. I've been on a number of projects where the bully ran it into the ground. The biggest asshole was able to impose authority but wasn't really very bright. I've more situations where struggles between two people to assert authority over each other became more important than getting things done. Anarchy is not a strategy.
Yeah. THAT works.
How would you suggest moving a stuck team forward?
Don't start a project without a leader. If the project was started without a leader, management should pick one fast.
I think if I wear a cheerleader skirt I'll get fired.
That depends on where you work I suppose.
But seriously, more often than not a team contains a least a couple members who will fight against any sort of progress. Sometimes these people are directly opposed to the project. Sometimes they simply fear the project leaving the domain that they understand...especially when their domain is making pretty powerpoint slides. Either way they work to keep the project stuck.
Someone needs to make them move.
And that person should be the official leader. Throwing a bunch of geeks in a room and seeing who comes out alive might be a funny experiment but it's not a recipe for success.
|
|
|
Message #245594
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Interesting points
What I have seen happen when there is no clear leadership is that often one person will attempt to make themselves the leader by bullying others.
As opposed to saying pretty please will you all work together?
No, opposed to having clear roles and leadership responsibilities. The idea that a project can be run by a bunch of people all 'doing the right' things smacks of the fallacy of communism, IMO. I've been on a number of projects where the bully ran it into the ground. The biggest asshole was able to impose authority but wasn't really very bright. I've more situations where struggles between two people to assert authority over each other became more important than getting things done. Anarchy is not a strategy.
And this was my point no.3 be brave don't be afraid or intimidated by anyone! People can easily get intimidated by others and abide to their ruling. Many people confuse being a people person by being bossy or by intimidating other to do they want, or if someone knows ur kinda shy, he can play on this too. Having people skills is really key here.
Yeah. THAT works.
How would you suggest moving a stuck team forward?
Don't start a project without a leader. If the project was started without a leader, management should pick one fast.
And that would be following the PMI standard thingie, each project should have one project manager, the idea isnt for him to be the boss, but, management need one and only one responsible for a project, for if the project fails or is late, they is a sinlge point of responsibility, else everyone will say "it wasn't me, wasn't my fault". When everyone in the team knows that only this one person will take the blame, they in normal cases do as he want whenever there is a conflict or anything, maybe out of pitty, i dont know, but most ppl i met act like this!
|
|
|
Message #245607
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The brilliance of Agile
Try selling a client on the statement "we're not exactly sure how many iterations this will take but we're sure it will cost you less than a waterfall approach...
Here's how it works in a nutshell. At the beginning of the project you get every user story in good shape and have the developers estimate them. You begin your first iteration, pulling in what the team feels is a realistic number of user stories to complete. This is done over and over again the progress, measured in accepted user story points, is plotted on a chart called a burn chart. After three of four iterations (velocity is small and volatile at first) you have enough information (user story points per iteration ) to get an idea as to whether or not the project is in trouble. I'm being real with all of you, there is nothing exotic here. If someone in your organization, or an outside consulting firm is not doing this and they are calling it Agile, then they are probably new to this.
and no we won't give you a fixed bid or delivery date commitment."
ThoughtWorks has delivered successfully under both of these conditions.
|
|
|
Message #245608
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The brilliance of Agile
It lets you go to a client, and sell them a never ending project and absolve yourself of any failures.
Try to look at it as though it gives you the opportunity to fail fast. By fast, I mean at the end of the first iteration (and every one after that). If your team doesn't produce working tested software at the end of each iteration, find the problem (whether it's the consultants and/or on the client side) and fix it. Retrospectives are a good time for this.
|
|
|
Message #245610
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The brilliance of Agile
So when a project fails, well, it's just because the project didn't follow the methodology, and Agile consultants are absolved of any responsibility (we TRIED to tell you to follow the methodology!)
Projects can fail for a lot of reasons, even if the methodology is followed. If your consultants are telling you that their process is somehow above this, consider doing business with someone who is more realistic. Also, you should be holding them responsible for delivered working software at the end of each iteration.
Not only do you never have to accept responsibility for any failures, but as requirements change you just keep tacking on more iterations.
Changing requirements can shorten or lengthen a project.
|
|
|
Message #245646
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Official Leaders
And that person should be the official leader. Throwing a bunch of geeks in a room and seeing who comes out alive might be a funny experiment but it's not a recipe for success
What happens when you are a developer, or other tech expert, and the official leader simply doesn't cut it?
This happens a lot. Lack of leadership does not necessarily imply lacking an official leader.
|
|
|
Message #245649
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Interesting points
No, opposed to having clear roles and leadership responsibilities. The idea that a project can be run by a bunch of people all 'doing the right' things smacks of the fallacy of communism, IMO.
Not really communism. In capitalism people are just supposed to follow there incentives and it magically turns out to be good in the whole. But I agree, that's not exactly a good way to run a project.
I've been on a number of projects where the bully ran it into the ground.
I've been on projects where weak leaders have let the projects go out into limbo. There are all sorts of types flawed leadership that can destroy a project.
The biggest asshole was able to impose authority but wasn't really very bright. I've more situations where struggles between two people to assert authority over each other became more important than getting things done.
Yes, I've seen that as well. Or were one persons struggle to brown-nose executive management takes precedent over actual progress. I've seen that a lot.
Anarchy is not a strategy.
Sure it is. Just not a very good one.
I think the real question here is: In an absence of effective leadership, should a developer stand up and attempt to lead?
That's a very personal question, and very context sensitive. Most people I know will not do it.
What you need to recognize is that there is a difference between leadership and authority. Your "bully" is attempting to gain de-facto authority. He is not attempting to lead. There is also a difference between leadership and management. The PMI project manager will track everything as it runs into the ground.
Leadership is something different. I know that's cliche, but it's true. Leadership is hard, and often not present.
|
|
|
Message #245653
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Official Leaders
And that person should be the official leader. Throwing a bunch of geeks in a room and seeing who comes out alive might be a funny experiment but it's not a recipe for success
What happens when you are a developer, or other tech expert, and the official leader simply doesn't cut it?
This happens a lot. Lack of leadership does not necessarily imply lacking an official leader.
Actually I don't think we really disagree much on any of this and that you just misunderstood what point I was making.
There's a couple of ways to look at what you are asking me. In the military, an lower rank trying to take leadership against the desires of his commander is called insubordination or mutiny and is a crime punishable with court-martial. I don't necessarily think that software projects should be run like the military but I think it's worth considering why that is the case. Do you not see a downside to anyone who feels they are smarter or more adept attempting to assert authority over others?
I think that what you have experienced may be similar to what I have experienced, that the management of a project or group is so bad that they only way things get done is if someone in the trenches takes control.
From what I know of you, it wouldn't surprise me if you have done this successfully. My guess would be that you would be closer to 'benevolent dictator' than 'tyrannical despot' on the spectrum of self-chosen leaders.
But without a clear leader, project success is a dice-toss. You might have a natural leader who will rise to the occasion with a team of people who are agreeable enough to follow good leadership even when it's not official. You might have a couple hyper-aggressive jerks battling over who will control a bunch of sloths who probably won't listen anyway. If you know you have a good leader on the team and expect them to lead, you should make that official and make their job a lot easier.
I guess my point is that teams without official leaders represent a failure of management. Even if the official leader is poorly chosen, everyone knows where they stand and the failures and successes of that leader can be evaluated. And in the case where a 'true' leader make things happen while the official leader hangs back, either the 'true' leader or management should attempt to correct the situation. Honestly, I think this doesn't happen as much as it should.
In the end, my whole point is that the idea of a self-managing teams is a crock. It's a big gamble and the larger the team, the less likely it is to work. I do think that avoiding micro-management and giving everyone the opportunity to make decisions and take responsibility for their choices is a good idea, however.
|
|
|
Message #245654
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Interesting points
No, opposed to having clear roles and leadership responsibilities. The idea that a project can be run by a bunch of people all 'doing the right' things smacks of the fallacy of communism, IMO.
Not really communism. In capitalism people are just supposed to follow there incentives and it magically turns out to be good in the whole. But I agree, that's not exactly a good way to run a project.
Well, in the original Marxist idea of communism, as I understand it, eventually the government dissolves once the system of everyone working together is in place. The authoritarian or totalitarian state that we associate with communism is, in theory, just a temporary situation.
The reality is that people need incentives to work and will react extremely negatively when they perceive unfairness such as they are doing more but receiving the same (or less) credit. Having clear leadership allows the incentives (pay) be tied more clearly to the success of a project and less so to personal goals or desires.
|
|
|
Message #245657
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Official Leaders
Actually I don't think we really disagree much on any of this and that you just misunderstood what point I was making.
...or perhaps I'm trying to incite debate...
Do you not see a downside to anyone who feels they are smarter or more adept attempting to assert authority over others?
I see a huge downside. As I was recently informed (by a guy encouraging me to come work for him), I have a problem with authority. Authority is kind of like nuclear weapons. One should only use it as a last resort.
I think that what you have experienced may be similar to what I have experienced, that the management of a project or group is so bad that they only way things get done is if someone in the trenches takes control.
From what I know of you, it wouldn't surprise me if you have done this successfully. My guess would be that you would be closer to 'benevolent dictator' than 'tyrannical despot' on the spectrum of self-chosen leaders.
I've both succeeded and failed. Right now I'm actively avoiding such situations.
What I'm trying to figure out is how to foster the rise of an acceptable leader within a headless team. Part of this is learning how to take the reigns without pissing off the good team members.
Even if the official leader is poorly chosen, everyone knows where they stand and the failures and successes of that leader can be evaluated.
Sometimes I wish I was patient enough to let this happen, but I simply can't sit back and watch a project I'm on fail.
In the end, my whole point is that the idea of a self-managing teams is a crock. It's a big gamble and the larger the team, the less likely it is to work.
I think crock is the wrong word. Different teams need different amounts of leadership. It's possible to establish a small team that can work without a clear day-to-day leader as long as you have high performance people with clear roles and direction. Basically if some of the primary leadership tasks have already been accomplished.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
