there seems to be an ebb and flow for this sort of thing. recently i read a discussion on the idea of a technical business analyst and how the business analyst role is evolving in project management. there was an argument that business analysts [ba's] are like wait staff. wait staff ask the customer what they would like and submit an order. they are never asked to go into the kitchen and cook. so why should a business analyst get into the pit and code?

if we continue with the metaphor above, customers are constrained to those items on the menu as well as the types of substitutions they may request of the kitchen staff. a good, or well trained, wait person will know these nuances very well and coach the customer to meet these constraints. if the waiter is unsure, they might ask if a request is appropriate before committing to the customer. otherwise, they will have to tell the customer that they have made a mistake committing to their request, or that there is a slight up-charge for doing so, or it may take a little longer to prepare. the story could continue, but i think this is a probable scenario.

my first question is, is this an appropriate comparison? does it hold water? in general i say no, but if we expect as much from an agile business analyst then it could be. based on my experience, there is usually a highly adversarial and dogmatic approach in favor of the customer by ba's in an agile software development environment. this may not be acceptable or typical, so i admit to a potential bias.

ultimately and imho, absent specialized skill sets (which is the direction of the industry in general), distribution of effort is delegated to the other people actually doing the work. for instance: in an agile development organization where ba's are limited, the responsibility is delegated to other members of the project delivery team, be it the pm, dev, qa members, etc. is it as high-quality as what a ba might produce? maybe, maybe not. but we know that the division of work is distributed, as developers are asked to have business acumen, qa is asked to do some development, etc. expertise is expensive, and very few are worth it despite the skill being sought.

so another question would be, what makes the ba a specialization that should be maintained in the field?

ba's work for both sides in an agile context. the walls are crumbling between business and technology. 'us and them' is becoming 'we'. i don't think it helps to compare ba's to wait staff. let's change context for a moment. in most automotive service departments you're not likely to find specialized technicians (tranny, engine, electrical), but technicians will have varying degrees of proficiency in each. your vehicle will go to a single technician or team of technicians to complete as much of the work as they can. rarely does a service call require an overnight stay any more, because the engine guy is backed up by a team of generalists. now an argument could be made that the service advisor is a better analogy to the ba. i argue that when the problem is complex, the customer suffers from an 'expert' translation. a good advisor offers tons of communication about where the work is and when the customer can expect to be done. they may also advise on trade-offs so the customer can decide to only do what needs to be done now and return later for the rest.

what are your thoughts on the matter? should ba's be more integrated and more technical? to what extent? how can the customer benefit from a more agile business analyst?

"success is the goal and is deterministic, exercise those actions that increase the opportunity for success. the rest will happen naturally..."

i am a marine, husband, father, brother, son... i exercise leadership on a daily basis. deliberate and intentional leadership building and execution is not the norm for many organizations i've been a part of. most expect it to occur because it's something you "have" or obtain by "proximity". managers are expected to be great leaders because of title. leadership has been decomposed into specialized definitions for use in specific scenarios. seems an insurmountable set of obstacles. i'll agree that there are different kinds of leaders and leadership styles that are more appropriate and effective given the individual and context. this is especially true in agile development teams.

the position of leadership is typically described as someone forging the way, as an ability to influence a group toward a goal. this has been interpreted as either being able to keep ahead of or setting the pace for the masses. i suspect many have experienced this form of leadership. most may even agree that this works. my experience is this is temporary, inconsistent, and accidental. here are a few principles i keep in mind as i hone my leadership capabilities. these have been in practice for many years by many great leaders.

marine corps leadership principles: (slightly modified)

• know yourself and seek improvement: everyone has their strengths and weaknesses. know what yours are. exploit your strengths and improve your weaknesses.
• be technically and tactically proficient: before you take on the task of leading, know or have experience in the domain you expect to lead. respect is the reward for competence.
• know your team and look out for their welfare: this is important. know your members. create a safe environment for both failure and success.
• keep your team informed: communication is key. provide enough information to do their job intelligently and to inspire their initiative, enthusiasm, loyalty, and convictions.
• set the example: set the standard for conduct by personal example. if your standards are high, expect the same from your team.
• ensure the task is understood, supervised, and accomplished: this goes back to communication, creating a safe environment, and setting the example. be clear and concise, speak to your team, not at them. allow your team to utilize their own techniques at times, while actively supervising.
• train your team as a team: teamwork is the key to success. insist on teamwork. train, play, and operate as a team. ensure each member knows his/her role and responsibility within the team framework.
• make sound and timely decisions: you should be able to evaluate, estimate, and make sound decisions based on your experience. this inspires confidence in the team. once you make a decision, stick with it, until you discover it's the wrong one. then don't hesitate to revise the decision.
• develop a sense of responsibility among your team: members that accept tasks and are given the authority required to accomplish the task builds trust among the team. trust demands responsibility toward the team goals. this becomes a self-feeding mechanism for high performance.
• employ your team in accordance with its capabilities: seek out challenging tasks for your team, but ensure your team is capable and prepared to successfully complete the tasks.
• seek responsibility and take responsibility for your actions: actively seek out challenging opportunities. own the opportunities you are given, including everything your team does or fails to do. never allow another member to own failure due to your mistake.

"i'm not concerned with your liking or disliking me... all i ask is that you respect me..." ~jackie robinson

i'd like to spend some time talking about respect, or organizing for respect. specifically in context of a collaborative vs cooperative agile team environment. i think this context will provide enough familiarity for most while providing a point of reference for others.

respect [verb]: to show regard or consideration for: to respect someone's rights. ~(dictionary.com)

can cooperation occur irrespective of any individual's respect for another? imho - 'yes'. to effectively cooperate with others, you usually require a binary response toward those you need to cooperate with. 'can i or can't i work with him/her?' or 'do i like or dislike him/her?' the more positive responses you have towards the others, the more effective the cooperation will be. should conflict arise among this kind of team, the results may vary based on the dynamics:

•  the majority influences the minority [mob rule]
•  a group reaches consensus to avoid conflict [groupthink]
•  the minority remains silent to avoid conflict or being ostracized [spiral of silence]

 ~ (wikipedia.com)
 
there are other plausible results, but so far, none seem conducive to 'me' thinking that leads to 'we' thinking, or inline with a team environment where respect exists for others. that is not to say respect does not exist on a cooperative team, just that it's not necessary or required. agile teams organized in this way will typically find guidance from a single source, either an individual or a sub-group of the team, utilizing a fraction of the knowledge and skills to execute on the goal(s). total ownership may not exist because a portion of the team conceded in some way. quality suffers in every way: definition, analysis, construction, and testing.

on the other hand, can collaboration occur irrespective of any individual's respect for another? imho - 'no'. i think respect is essential for collaborative agile teams. collaboration incites conflict. reasoning and results are challenged to gain a shared understanding of the goal(s). input is provided by all, digested, and actioned based on gained knowledge. those involved participate, challenge, and compete with one another to gain consensus. the process is facilitated for, rather than guided toward, progress. there simply exists a certain level of respect to accomplish this kind of team environment.

successfully collaborative agile teams require a level of respect not essential for cooperative teams to accomplish a similar set(s) of goals. i think respect is present for each team. in a previous post on 'pride' i mentioned 'me vs we thinking' and how the subtle differences have contrary organizational systems with impactfully differing natural consequences. collaborative and cooperative teams are contrary organizational systems. 'respect' is a natural consequence of one and not the other.

fun interview format: lean kanban & scrum sprints

-: thank you for joining sidebar. i'm your host - (dash) and our guests for todays format will be lean software development and scrum development process. please welcome them... (applause) ;p
scrum: thank you for having me. it's a pleasure to be here.
lean: yes, thank you. what a great looking audience you have today.

-: excellent~ well let's dive right into it shall we? we're here today to figure out some things. before we get too far can you briefly summarize what you do? we'll start with lean then alternate as we move forward.
lean: well, we focus on defining the workflow and understanding how long it takes for work to move through each stage. we do so by limiting work in process (wip) by stage, dealing with impediments as needed based on exceeding these limits, and provide the opportunity to deliver working software as soon as the work is completed.
scrum: ok, we focus on defining process rules and norms to drive a more collaborative team dynamic within these boundaries. we also limit work in process (wip) by batching work in timeboxed sprints, communicating impediments verbally, and have a goal to deliver working software at the end of each sprint.

-: that's great. thanks for the summary. but it sounds like each is pretty similar. could you describe what the differences are?
scrum: right~ we focus on, optimize, and batch work in a timeboxed sprint. sprints are the boundary conditions for observation and feedback to everyone involved. we find consistency the key to predictability.
lean: with that --- we focus on and optimize the workflow for each work item. we pull work as needed, providing observation and feedback at each stage in the defined workflow. we find optimization within your current working conditions the key to improvement.

-: ok~ then why not the other approach? in a couple of sentences if possible... let's keep the gloves on folks ;p
lean: lol~ if priorities change, we don't make you wait until the next sprint, just until the next opening in the queue. we simply focus on limiting the work rather than the conflict that arises from increased concurrent items being worked on. generally speaking we don't have rules that can be broken putting your project at risk, rather you are alerted and have the flexibility to resolve the alert as needed.
scrum: good stuff~ so we won't let you flounder about trying to figure out how to deal with "things". there is guidance, from there you have liberty and ownership of your processes. we won't vary widely on how to do "things", so if you ask most people "how" something is done in a specific context, you'll find most answers to be fairly consistent. generally speaking, people get things done, so we deal with the things people need to get them done.

-: nice~ seems like two very good approaches to managing work... thank you both again for being our guests today. we hope to see more of each of you as people learn more about the value provided from your approaches.
(both - lean & scrum): thank you for having us... (smiles and waves) ;p

i've gotten a couple of questions lately about kerberos and v1. so i thought i'd put together some things that i've learned in my research on the topic.

this isn't a lesson on kerberos, which means there is an assumption that if you're interested in using kerberos, you're up to speed to some degree.

so we'll start with a couple of facts:

1. versionone supports integrated windows authentication
2. integrated windows authentication supports kerberos. yep, that does mean versionone and kerberos do play nicely together.

when installing versionone you will be asked to choose either versionone or windows integrated authentication mode. if you choose windows integrated authentication, versionone delegates authentication of the user requesting resources to iis. iis attempts to use the current user information on the client computer. since versionone is a web application, a web browser is the client application requesting resources from iis. i mention this to point out that most configuration issues will be either iis or the client web browser being used, assuming kerberos is working for other systems.

note: authentication is delegated to iis, authorization and access to project data is still managed within the versionone application. which means the member list is required and maintained by a versionone administrator within versionone.

so there you go... as quickly as possible i tried to provide enough info about kerberos and v1. for more details i will provide a few links that helped me. enjoy~

http://www.adopenstatic.com/cs/blogs/ken/archive/2006/10/20/512.aspx
http://support.microsoft.com/kb/215383
http://support.microsoft.com/kb/326985
http://msdn.microsoft.com/en-us/library/ee825205(CS.10).aspx#cs_gs_security_zhsy
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true
http://gregjessup.com/firefox-kerberos-authentication-2/

"pride is a personal commitment. it is an attitude which separates excellence from mediocrity." ~william blake

a group of people does not make a team. cooperation does not equal collaboration. doing things does not mean they are the right things. a team that collaborates will ultimately do the right things. a mediocre team will consistently out perform any group of excellent individuals. these statements are not just my personal opinion or bias... these truths can be distilled from agile principles, case studies, or your own personal experiences.

i was fully indoctrinated in this way when i first stepped foot onto parris island, sc, marine corp recruit depot, december 1991. today, thirteen years after my last day of active duty service to my god, country, and corp... i have the pleasure to make the claim that "i am a marine". i earned it, i believe in it, and i am proud of it. i share these sentiments with many of the software development teams, both agile scrum / extreme programming and traditional phased / waterfall, i had the great pleasure to participated on.

in my experience, being a member of any team requires a sense of pride. pride in oneself, the other members, and in the day to day activities executed in concert with the team. it's amazing what a single team can accomplish when there is a shared sense of pride in everything done, both together and apart. take a moment to consider this. i'm certain it won't be hard to identify a time where your own pride contributed to the success of your team. band, sports, choir, projects... it is an infectious motivator, it helps to lift up when there might otherwise be a reason to be down, it causes an entire team to focus on quality execution, and may even be the single difference between a teams success or failure at times. despite or maybe as a consequence of this the team owns the results of their efforts.

lets determine what it takes to lead a group of people through the process of becoming effective team members with a sense of pride that extends beyond 'me' thinking. foundationally this requires a system that fosters 'we' thinking. most can agree that usually starts with a single achievable goal, which may require individuals to commit to a portion of what it will take to achieve that goal. notice the nuance of 'individuals to commit to' and 'to commit individuals to'. semantics? it's the same subtle difference between 'me' and 'we'. each will produce a system with contrary organization to one another. each have impactfully different natural consequences.

team pride is the natural consequence of individual pride. i began with a quote by william blake because it encapsulated the essence of the fundamental way of 'me' thinking that produces 'we' thinking. "pride is a personal commitment." don't wait for leadership to forge the way, become the leader. take pride in the things you do, what others do, and own all of it. during your next team retrospective, observe each area of possible improvement that is raised. add pride to the equation, postulate potential impact(s), and test the assumed result(s) against each observation. could you expect improvements? could things get any worse? doesn't it warrant an experiment?