archive-com.com » COM » I » INTEGRUMTECH.COM

Total: 312

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Episode #113 - High Costs and Negative Value of Pair Programming - Integrum
    comparison I would even say that if your software project is so simple that you can just crank out lines of code then you probably don t get any benefit from pairing as far as collaboration or redundancy or anything Clayton You probably don t get any benefit from collaboration of any form You should probably just outsource and try to get your code written as cheap as possible Roy Right because if all it really takes is that you just are pumping out code then you can just replace that person with someone else and it doesn t matter But that s not the case I think in most software organizations Clayton I was going to say how many projects are actually out there where you can just put anybody in front of it and pump out code Roy A lot of people try and do that especially I would say shops that are doing outsourced software development where they re solving the same problem multiple times They probably do just have a set way of doing things where they could get pretty close to just pumping things out and it doesn t really matter who s working on it But for most organizations that are developing either products for customers or developing products for internal customers where there is a need for that collaboration and giving some creativity and having that redundancy so that you don t have the single point of failure with the one person who knows everything Clayton That s true That s one thing that s not really acknowledged all that much I believe one of the lines in that article states something about like If you look at the data in Table three you can clearly see that the most efficient course of action is to hire a bunch of individual expert programmers If you ve followed many of our podcasts in the past then you ll know that that does not really fly very well with the way we like to work and that that sets organizations up for failure because you end up with all of these single point of failure where if any one of them Each one is a link in the chain and if anyone is gone then the organization falls apart Roy The single expert programmer is usually a hero and a cowboy They are the ones that are going to stay up until 3 00 AM heroing some solution for some problem and then they re going to cowboy code their way Clayton They re pumping out lots of lines of code Roy Yeah exactly and they re going to cowboy code their way through everything else If you ask any IT hiring manager the idea that you can just go pluck expert programmers off the street which to the author s credit he does make the point that that probably only makes up about 10 percent of the hiring pool that s available the programming talent I feel like that advice is You should only hire expert programmers is like telling your little sister You should only date guys that are really nice to you and that are financially secure and that treat you with respect That s not going to be everybody in the world That s probably not very good advice right Clayton I don t want my sister dating everybody in the world though Roy I agree but the idea that a hiring manager is just going to go out there and find some expert programmer and say Hey we can solve all of our problems by hiring three of you instead of having a few pairs That seems silly Clayton It s short sighted too to think of things in terms of moving faster because you have a pair because it s a single person moving faster If you have a single person making poor decisions and maybe moving very quickly but creating this monstrosity that s going to be impossible to maintain sure you re moving faster for now for the next few weeks But then all of a sudden when defects come in or change requirements come in or whatever and you start needing to adapt the system to meet the new demand that s all of a sudden when things start to slow down because you didn t slow down to begin with Roy Yeah The way that the example is set up in the article it s very tipped in favor of the single programmer and not in favor of a more I would say real world scenario or at least a scenario that we see with our clients that have a dynamic application or a legacy system or they re trying to build a new product They need lots of creativity and they need that collaboration so that they can get lots of different ideas and so that there s the redundancy Those are the things they need They don t need people just pumping out code Clayton That s I think we see in almost every organization that I ve ever worked with The biggest problem has always been with figuring out what to build Not building something quickly Building something as fast as possible has never been the issue Roy I would say the other thing I think that we see a lot is there are scenarios where saving money is a beneficial thing I think this article comes from the standpoint the fact that they bring it up in the very beginning that Agile is sort of not very good with economics Or at least that s the claim they re making Drives to the point I think where all they really care about is the bottom line Which you know I think if you spend enough time in the community you realize that going faster and more better faster cheaper That line which is I think how a lot of people view

    Original URL path: http://integrumtech.com/2013/07/episode-113-high-costs-and-negative-value-of-pair-programming/ (2016-04-26)
    Open archived version from archive


  • Episode #109 - Revisiting Decisions - Integrum
    you find a better idea great but your situation changes as well You are no longer in the same green field state at the end of the course of the decision right Like in our example you re no longer at that same state where you haven t built this feature yet You now have something That changes the scope of your decision You can t think of it in the exact same mindset as before you started it Roy Do you think if you re using the decider because of the format for the decider protocol and the way that it is basically so structured to deliver that consensus you never really are revisiting things because you are always making a new proposal to improve Is that kind of what you re getting at I guess Clayton Yes it is but I have definitely found myself in certain cases with the decider feeling myself a little bit conflicted because I felt like I had a better idea that completely against the previous Decider and as part of accepting thumbs upping or glad handing a decider you promise not to sabotage the decision Sometimes I feel like I m sabotaging the decision when in reality I m actually proposing a better one Like I m not really sabotaging it because everybody else on the team has the opportunity to thumbs down it right I m just presenting the time with an alternative choice Roy I think everyone can probably think of somebody that they work with on their team that has a tendency to maybe revisit things or revisit decisions especially ones that they were not part of Do you think that s something that a team should really be concerned about If there are people on the team that are always bringing kind of the old decided stuff should they go out of their way to avoid making decisions until that person is there Clayton No I think if you re see I ve been thinking about this because I ve been experiencing something very similar and I think what is important is that if you are not present at the time the decision is made and you come back and you have some additional information you have the responsibility to disclose what you know Then it is up to the team to choose whether or not to revisit that decision I would say it would be good for like you to make a decision me not to know about it come back find out and then say like Oh Clayton by the way were you aware of this Give you some information What would not be acceptable though is me pushing the agenda and the opinion I have I wouldn t be like Clayton you are doing it wrong We need to do it this other way Let s undo your decision and do it my way instead That s a totally different message than Here s some new information what would you like to do with it Roy I guess I feel like the reason that people there is turnaround like revisiting decisions or at least the intent most of the time is the people who will want to revisit things aren t doing it just for the sake of conversation or they re genuinely curious about why the decision was made A lot of times I think they think that there are some drastic like the train s going to go off the tracks if I don t step in and tell them this new information A lot of times I think that s why it s so difficult to have those conversations because it s not from necessarily like a rational Let s move things forward It s from a Everything s going to fall apart unless you listen to me and we talk about all the reasons why you made that decision all over again Clayton Yeah it s a difficult situation to be in I can understand that emotional need and sometimes I think I may even be a legitimate thing right Like you might actually have mission critical information where you know the train is going to get derailed but it s really tricky on a personal level to make that determination Roy Do you think in a situation where there was something that was kind of extreme like that would it be appropriate for a team member to come back and say Hey I know you guys decided that without me and even we decided that we were going to do this way but I know this new information X Y Z I think we need to re decide We need to revisit it Clayton I don t know if it s like a revisiting decider or it s like a Hey here s some new information I propose we revisit this decision One two three and then you can just throw it aside on whether or not to Roy Even if they weren t the team wasn t trying to use the core protocols you were just making a proposal But for us teams that aren t using the core protocols it seems maybe it s a fine line between when it s appropriate to revisit it and when it isn t Clayton I think if you have mission critical information and you bring it up and the rest of the team hears it and they don t say Oh you re absolutely right We did not consider that Let s revisit this decision then it s not important enough to revisit the decision However important you think it might be right I think you re going to have to lean on the knowledge of the team Where if the entire team hears this piece of information and decides it s not important it s not important Roy I think another aspect of this whole thing is the feedback loops

    Original URL path: http://integrumtech.com/2013/05/episode-109-revisiting-decisions/ (2016-04-26)
    Open archived version from archive

  • Episode #131 - Autonomy, autonomy, autonomy. - Integrum
    are in their cages have Like Yeah I know I m not free and I know I don t know how good I could have it but it might also be really scary and difficult and I don t want to deal with that I d much rather stay in here where it s safe and I ll just come to work from nine to five do what I m told go home and I can be my true self the rest of the time Derek It s pretty crazy because if you look at some of the best companies in the world they switched from trying to hire the brightest people to hiring the most impassioned autonomous people Meaning good companies learned that one of the easiest ways to scale is to hire people who are capable of knowing the right things to do and doing them and not needing a whole lot of management Needing some leadership to push them along What you re seeing is some key areas around the world that are attracting the most people like that because again once you realize that freedom and you see what that looks like and you re attracted to it people that are interested in that are flocking to those areas You re starting to see other areas be able to not compete nearly as much The big Fortune 500 companies are having a harder time getting and keeping good people They re losing them to the five person company that s becoming a 100 person company all the time I think that that s hard A massive culture change has to take place What we see in most companies we go into is their middle management and upper management got to where they were at because they were really good at removing autonomy To come in and say Nope you need to go the other way and let people be autonomous that is just not in the nature of the people that are there Jade What does autonomy look like in an organization on a team Roy I think on a team by definition if a team is autonomous the team itself has to be very flat Having any form of hierarchy within the team kills the autonomy because then really you only have autonomy at the top of the team The entire team is not autonomous You know what I mean Derek Right I think the more authority structure you have the more easy it is for people to defer accountability Roy Hide behind authority figures Derek I think they can hide behind the accountability It becomes if Jade and I need to make this decision and you re the boss and we re not really sure on it Roy Or you making the decision s going to hurt Jade s feelings even though you know it s the right thing to do Derek Whatever the case is there s contention of some kind around and is this the right decision We could be wrong If there s a boss we can go and say We re not really sure what do you think crosstalk Derek We ve removed the autonomy away from ourselves and put it into your hands which would sound bad compared to everything we just said but what we re doing is now we re moving the accountability to you Now once the accountability is yours the problem is now you re going to want to control more and more things because you re the one that s going to be held responsible when somebody comes to Jade and I we go It s not our fault Roy s the one who told us Roy I m incentivized to start micromanaging the crap out of you guys because now I m on the hook Derek If you flatten that structure or eliminate some of that authority chain it takes away the human nature to try to push the accountability to somebody else Jade That s the flip side of the coin for autonomous teams is they are highly accountable teams Derek That is correct Roy That forces you guys in the hypothetical scenario you guys would be forced to make better decisions because you are being held responsible for it You cannot just even though you think something is the right thing like you might chose not to do it Like characterization Derek It at least gives us the opportunity to make better decision Jade You might be still dumb on purpose crosstalk Jade Well that s your problem Derek It s hard not to care anymore because whatever the result it we are responsible for that so even if we are not super passionate about it whatever it is we are doing we probably care about what the result is because there is something else that we care about like I do If I need to bring a pay check home to pay my mortgage I care about that I get a pay check so maybe I am not super passionate about this particular thing but I am passionate about pay check I can no longer just say I don t really care The day if it goes wrong Roy is going to get fired not me and know if it goes wrong I have got to start to care about this thing at a different level Jade So the simple definition of autonomy is self governance within a limit What does it look like in an organization made up of autonomous teams How does that even function Derek How does it scale Jade Yeah I didn t say that how does it function Roy When you have more than one autonomous team Derek Some of it depends on how much of these teams need to interact with each other right I mean I think where we have seen it go fairly well is when they are able to break them

    Original URL path: http://integrumtech.com/2014/02/episode-131-autonomy-autonomy-autonomy/ (2016-04-26)
    Open archived version from archive

  • Episode #39 – What is the Right Iteration Length - Integrum
    as much as I might bag on it on a 30 day sprint or a four week sprint as long as a team understands that that s a segment of where they re at not where they should be going I get concerned when somebody starts with a one week sprint and then pulls back to a two week sprint and says For us just a two week sprint works better Because what they re really not acknowledging is all the problems that are keeping them from being able to do a one week sprint I see teams do one week sprints all the time really really effectively which means it s doable If it s not doable for your team there s probably other symptoms that are happening Either you ve got poor deployment practices You have bad product ownership You have poor planning meetings A myriad of different things can be coming up that are preventing it from it Sometimes when people kind of roll back to this less than ideal state if they don t do it with a We re only doing this for right now until we can get better at the other things then I think that that s dangerous Jade I think that there s some huge downsides too to doing one week sprints I m sorry Downsides to not doing a one week sprint specifically when it comes to regards to research tasks If I m doing commitment during planning and during my planning meeting I find out that I don t have enough information and I need to write research tasks If have a one week sprint then it s relatively low cost I spend one week doing the research In the following week I can immediately do that task If I have a four week sprint that means I do the research task That even means it s four weeks until I do the research task Then I don t commit to getting it done until four weeks after that It s going to be eight weeks until that story gets done Or I do the research task immediately but then it would be four weeks before I actually address the story Then it s four weeks between research tasks Derek But if it takes you nine weeks to deploy that s all OK laughter Chris Something that we re talking about is that some of these teams that we hear when they re doing one week and then they go to two week how many times do we hear it s right in the very beginning You re talking about retrospecting realizing What do we need to change where they re getting used to this so it s probably talking them longer than it would Are they really retrospecting going Are we getting better at this Can we stay at one week I have some questions in regards of what did the team think of and why did they

    Original URL path: http://integrumtech.com/2011/12/scrumcast-39-what-is-the-right-iteration-length/ (2016-04-26)
    Open archived version from archive

  • Special Episode : User Story Class Interview with Sandra Bufford - Integrum
    Perry Reinert Join the conversation on Facebook Subscribe to the podcast Make your mark Get involved with the Agile Weekly Podcast by volunteering to be a guest recommending a speaker submitting a question or suggesting a topic Step up to the mic Build up your toolkit Learn new tips and tricks for empowering your team and transforming your business See the blog Hungy for More Info Agile Weekly is a

    Original URL path: http://integrumtech.com/2011/12/user-story-class-interview-with-sandra-bufford/ (2016-04-26)
    Open archived version from archive

  • This is your client on Cucumber... - Integrum
    our 500 lines of Cucumber were too wordy or too technical The result Big win for both sides Not only did they force us to flesh out the design more thoroughly they had the same effect on the customer Here s some examples some minor some huge of what we caught for this iteration alone The client decided they want a GUI to crop uploaded images manually rather than auto crop This one resulted in a whole new story Setting up an account with the payment vendor should ideally be in an IFrame not a redirect Errors in account setup should result in a redirect to the setup page not just an error message Admin sidebar menu appears even for regular users it just has different entries The active page should be highlighted in the sidebar I accept the terms of service checkbox on the account upgrade page Upgraded accounts are called Pro in the interface not Premium Some of those would have been a pain to go back and fix later This is definite motivation to keep up with the time investment to write the stories We still need to get faster but it definitely keeps things from falling through the cracks PREVIOUS Does your Rails app need a bailout NEXT Episode 01 Single Retrospective w Multiple Teams 2 thoughts on This is your client on Cucumber Josh Knowles says March 11 2009 at 3 13 am Great to hear you re taking steps towards integrating Cucumber Let me know if you have any problems with it or Webrat Reply Isaac Weinhausen says August 18 2009 at 8 41 pm We just started using Cucumber too and used it in a similar way Surprised at home much it benefited our design iteration In that way they re similar to

    Original URL path: http://integrumtech.com/2009/03/this-is-your-client-on-cucumber/ (2016-04-26)
    Open archived version from archive

  • Cucumber Conversation from Clayton - Integrum
    Technologies on Vimeo PREVIOUS Want to work somewhere Awesome NEXT Episode 02 Human Driven Development Step up to the mic Cancel reply Your email address will not be published Comment Name Email Website About the author Jade Meskill Chief Revolutionary Officer The new normal presents us with many extraordinary opportunities To accept the challenge is to lead the way to a new future made from embracing our humanity and engaging

    Original URL path: http://integrumtech.com/2009/04/cucumber-conversation-from-clayton/ (2016-04-26)
    Open archived version from archive

  • Episode #128 - Smaller Teams - Integrum
    of for people it s hard to not be part of almost every conversation on inaudible 06 37 Roy Unless you choose to be Derek The other thing that I have been talking a lot about and I think this is a big part of mediocrity for a lot of teams is if you ve got 10 12 people even 9 people sometimes on a team and you have one or two really strong people and one really weak person on the team that weak person can really hide Because what happens is that the strong people can just pull harder or work harder or put more effort Roy Or shuffle the weak person around a lot Derek Shuffle the weak person around whatever What happens is if you ask them Why aren t you doing something about it Their answer becomes It s more effort for me to deal with trying to make the person that is hiding be exposed than it is just for the If there s the four of us and there s five other people on the team and one of them is really weak we just say Hey the four of us will cover what the other person s not doing That s easier than having all of the emotional stress of dealing with somebody who s not performing But you get on a four person team it s no longer OK I m sorry the two of us are not going to pull the slow guy It s just not happening because now it s a Herculean effort instead of Eh it s kind of painful but So two things happen Either the guy that s hiding figures out really quick I can t hide and decides to go somewhere else transfer somewhere else in the company go to another team leave the company Or they have to fess up and say Look I don t know I m lost I don t know how to do this kind of stuff I need help Usually what will happen is the team will embrace that and say OK if you want help I ll help you but I m not going to carry you anymore When we were in a 10 person team we all carried you around but now that there s only one or two of us to carry you around we re not going to carry you anymore But if you want help we ll help you walk That that is something that exposes very quickly when you get small teams It is so hard to hide when you re on a team of five people Clayton Yeah with the 10 person team that 1 person their negative impact I think relatively speaking is the drop in the ocean But when you re half the team when you re one fourth of the team and you have a negative impact you could do half a day s work that is bad and that really impacts everybody You can t avoid that anymore Derek And we tell lies to ourselves If we ve got 10 people and we ve got some work to do and it s like Technically Clayton really can t do anything inaudible 08 56 But we ve got this stuff that none of us really want to do so we can dump it on maybe we ve got some manual tasks we need to do or maybe we need to do whatever So we ll keep you around even though push comes to shove we don t even count your capacity in what we re doing but we know we can give you some stuff we don t want to do When it s four people and its You have to do four people s worth of work you can t go But Clayton doesn t count It s only the three of us Roy That s part of the problem though is if you have a team that isn t lazy enough Because I ve worked on a team where I think there were four or five people on there and we did it that exact thing happened a lot because the team wasn t lazy enough to automate all of that stuff They never got around to it because they could just always give it it was actually easier for them not to automate it because it gave the fifth team member something to do That cycle just kept going over there was no reason to ever automate there was no reason to ever inaudible 09 51 this guy up Clayton Pro tip if your team s slack is the same number as your capacity laughter Clayton there might be a problem Derek I think there was probably other issues going on there My point is that it becomes a lot harder to hide that If you re doing your capacity based planning and you ve got 400 hours and you re only hiding 20 hours you could explain away that slack pretty easily If you ve only got 80 hours and you ve got 20 hours of slack in the way I think pretty quick the product owners will go Man that seems like an awful lot of time for the amount of people here It becomes much more difficult to explain that away Jade We re saying that 10 person teams are a little large for us I think that s a radically small team size for a lot of people to say 10 people and we re saying That s too big How do people deal with this if they re in large organizations with pretty large teams what do they do to start changing the way that their teams operate to get more lean and mean to get more exposure to get all these things that we re talking about Roy I think it has to start with modeling view on in

    Original URL path: http://integrumtech.com/2013/12/episode-128-smaller-teams/ (2016-04-26)
    Open archived version from archive



  •