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 #70 - XP Practices with Arlo Belshee - Integrum
    it is learning to pair is fundamentally your learning a different language You think differently you learn to think in pair and it is a very different way of thinking It s critical to develop subconscious filters that are filtering your environment differently so that you re not being destructed by the noise but are subconsciously noting it When something comes up when a keyword gets mashed your subconscious mind fills in the last 15 seconds of conversation just like when somebody says your name The closest match we have is learning another language I really encourage teams to do that transition both as an experiment and like they re trying to learn a language which means that you define a period of time that we re going to try this experiment It s got to be at least three four weeks because we re talking about training the subconscious That doesn t happen quickly takes a month laughs You got to be three four weeks you got to expect that it s going to look really awesome the first day it s going to be sheer hell by the end of the first week You re not even going to be able to think straight Basically your mind is now trying to think in two different languages at once and everything is blocking itself That s what s going to happen in the second week I see a lot of teams don t know what to expect in that transition period They get into that first couple of weeks go Oh God Stop doing a hundred percent pairing and they say OK we need to back off Then they do 50 percent pairing which becomes 25 percent We re pairing certain types of tasks At that point you ve now switched from a more mature learning of a language to learning of a language in a high school classroom You re never going to get the accent and it s going to take forever You re never going to see the value that you do if you can actually understand what immersion learning is going to be like be willing to accept that and then make it happen Derek I ve got a question on getting to the transitions Let me give you two scenarios and tell me how you would approach them and whether it d be the same way or apparently different One would be I m a development manager and I ve really started to read about this XP stuff or maybe I ve worked in another company and we ve done XP before I really believe in it except none of my developers currently want to pair program How do I start that process with that transition Is it OK to just say I m going to demand that you all pair program and deal with it Let s talk about it in three weeks The other scenario would be Hey I just joined a new team I came from an XP team I really miss that and I really want to do that Maybe there s another person or two on the team that are interested in it pair curious or XP curious about things How would you go about coaching that person to moving to transitioning to pairing Arlo The meta approach is the same and then the details vary by the context The meta approach is to understand that people decide emotionally and then justify rationally Rationalization is called that for a reason is the only way we use the rational mind If you want to get people to make a decision to try pairing it s an emotional sell because they ve got an emotional commitment to the current one you ve got to change to that which means inspire for inaudible 10 02 Some of the things I have done here I did a code retreat There was a set of people That was the right thing We got together and a code retrieve you are doing everything paired Also most of the people around here don t have great tools I m showing them Resharper and I m showing them End Crunch and I m showing them all sorts of stuff that they can t work in their daily work because they re working in C on really old Legacy systems Bring all of those things together in a room Now pairing is something fun that I got to do for a day which allowed me to learn simultaneously this language and solve the problem and learn four or five tools and holy cow it was a successful day There I ve inspired That one works Another one is I can do a demo and show some of the things that are going to result and that can be another good way to inspire We did an exchange program for a little while which will be starting up again soon Where team could go visit teams from other companies Smilebox is just down the street They have a really good XP shop They do a lot of pairing and it s full collaborative style with everyone in one room and the devs and the marketing people and whatever can overhear each other and all the goodness When I could take people from the teams here over to visit that suddenly without having to learn pairing or commit to pairing they could see the value that comes from the collaboration and the learning Then we come back and we talk about how we will do that transition laughs Clayton I thought it was very interesting you hit on that transition part I think that s a very good point There s a team I d been working with where one of the guys was like I m so mad at Derek because he writes all this terrible code I m so mad at Drew because all he does is goof

    Original URL path: http://integrumtech.com/2012/07/episode-70-xp-practices-with-arlo-belshee/ (2016-04-26)
    Open archived version from archive

  • Episode #117 - Product Owner as the Customer - Integrum
    control manager to more of a servant leader right Whereas a development manager you start to think more in line of like How can I help the team Rather than How can I get the team to do what I want With the product owner that s a pretty common thing I ve seen on multiple scrum teams where the product owner start to take up the role of like the manager of the developers rather than being a member of the team I think that s a mistake it s very important to make the distinction between like You re the product owner not the team owner Clayton Derek you were sharing some drawings that you had about how you ve seen some team structure where the product owner is also the manager and they re outside the team or sometimes they re inside the team and sometimes they re also the scrum master and all these different things I thought that was pretty interesting I think in my experience There are so many product owners that don t ever treat themselves like a team Most of the time they don t except when it behooves them If there s a decision to be made or they re involved somehow and what the team is going to do next or something like that then they re definitely a part of the team When it comes to maybe being responsible for everything or like the not special treatment scenarios they always view themselves as like Oh I know I m just separate I m not part of the team I m this product person throughout the organization I report to the different tree Derek Yeah I think it s difficult I go back and forth between where I think the product owner really I definitely think the team should not be reporting to the product owner from an organizational structure or perspective I definitely don t see a ton of value in that or any value in that I see a lot of conflict I go back and forth between whether they re part of the team or not part of the team Certainly they re not part of this the development team or the product team or whatever you want to call the people doing the work Roy Right like they re not going to pair with one of the developers Derek Yeah but I get a lot of questions Should the product owner be a stand up Should the product owner be part of the retrospective A number of inaudible 08 48 and I get really indecisive because on one hand I really think they are the customer If we really think about it they are a proxy for the customer I don t think the customer should be part of the team but I think they should be in damn close proximity interacting with the team and collaborating with the team a ton When it comes to stand ups yeah they should probably be there just so that if the team has questions there can be some dialogue that happens When it comes to retrospective I don t know I m a little more at horn crosstalk Clayton retrospective because that s one pattern I ve seen a lot is the product owner will treat the retrospectives as optional Where when they think they want to be there or there s something that s on their mind then they re definitely going to be there and they re going to be the loudest voice in the room When there s some other conflicting meeting or maybe they don t have anything to say to that particular retrospective they treat it like Yeah I don t really need to be there I have seen where the team will make some decision about something that affects the product owner when they re not there and then they get all up in arms like Well hold on you guys can t make choices without me Well you optionally decided not to come to the meeting so what do you want Roy I feel like it is important for the product owner to be present at the retrospectives for exactly what you mentioned Just because they don t have a problem like the rest of the team might still so they want to bring up with them They probably should be bringing that up throughout the week but I totally think they should be part of the retrospectives They should be sitting with the team and participating in stand ups Other than having the authority to choose the priority of the work they should be a team member I agree they shouldn t be pairing on any of the work because there s a conflict of interest there but they should be involved in all the other ceremonies Derek One of the things I see as a problem with that is there becomes too much familiarity and then they actually do not do the product ownership role well enough If I m the customer of a service when I m no longer happy with the service I can voice very strongly that I m not happy I can even say I m so unhappy that I m willing to go get my service somewhere else I m sorry Target if you piss me off Wal Mart is more than willing to take my money and they re pretty close to the same thing Where if I work at Target it becomes very difficult for me to say Hey Target if I have a bad experience I m going to stop working here because I have a bunch of friends If I m negative about it then people stop shopping there and maybe I lose my job I see that happen with product owners they consider themselves too integrated into the team The benefit is there s more Hey we re all

    Original URL path: http://integrumtech.com/2013/08/episode-117-product-owner-as-the-customer/ (2016-04-26)
    Open archived version from archive

  • Episode #105 - Delivering News and Doing the Right Thing - Integrum
    t believe are the right things to do for the product pretty soon you don t care about the product Then it makes it impossible to do even the right things for the product Jade How do you start to reconcile that Let s say you re working with a team that s been put in this position where they know that what they re being asked to do is not the right thing for the product They re very resistant to doing whatever is being asked of them but yet they don t know how to address that or how to reconcile it with the organization Derek I think one of the ways that I would start to approach it is if I understood why the team felt that way it would probably depend on what the reasoning was and coach to that More often than not it s usually like We just think this is dumb Roy Right they think it s a waste of time Derek There s no value in it it s a waste of time What I would generally do is say like hey you might be powerless to do anything but you can do the exact same thing that you should expect people to do from you and that s hold you accountable to your action or ask you to be responsible for your actions What I would do is I would ask the product owner Why are we doing this Can we measure that this is moving our product forward Are we going to gain new customers if we do this Are we going to prevent losing customers if we do this Are we going to be able to up sell existing customers that we have How is this benefiting our product If they re not able to tell that story with data then I think you can push back a little be on them and say Man you know we would feel more passionate about this if we really knew that this was going to solve the problem I think that if you do that enough times what can start to happen is the product owner has to start seeing themselves for what they are which is hey I m just shooting from the hip just saying Do X do Y do Z I m losing credibility with the team in the same way that if the team just says like Oh we ll get stuff done we re going to get it done and don t ask us to look at anything Don t ask us to be accountable for our work or be responsible for when things ship the product loses respect or loses trust for the team If I never do what I say I m going to do and never produce results as a team the product owner gives up in the same way the team gives up if the product owner never produces results Roy But

    Original URL path: http://integrumtech.com/2013/04/episode-105-delivering-news-and-doing-the-right-thing-2/ (2016-04-26)
    Open archived version from archive

  • Episode #43 - Taking to the Twitters - Integrum
    they get to the plateau stage they have to start to say OK now we re going to start removing the but parts We re going to start saying how do we get to the real implementation and deal with what it exposes Clayton The next tweet goes towards some of the Scrum versus Kanban stuff but it says Scrum as a diet Kanban as a mirror This is getting at the Scrum makes you or suggests that you make some changes to your process where Kanban has got it more let s visualize what you re already doing This is an interesting anecdote It s a great tweet because it s link BD it s been re tweeted a few times here I will say there s probably a lot of overweight people who have mirrors in their house but that doesn t seem to help much I don t know what that says about this Derek I saw an excellent Ted talk in the last few days that talks about some methodology about a sailor going through where the sirens are located He wanted to hear the sirens but he didn t want to be lured in to the sirens He asked the captain the crew on the boat to actually tie him down to the mast of the boat so that he couldn t get out The theory there is that it s a commitment post All the time in life we use commitment post that say we re going to put something If I m losing weight maybe I say I m not going to let any junk food in the house Maybe I say that I m not going to go to these types of restaurants because I know that there s a weakness there and so I m going to commit myself to not being tempted by that At times some of what we do in Scrum would be a kin to that I don t know if a commitment post is necessarily a bad thing If you rely on it long term it s probably not real healthy I would pose it a mirror doesn t tell you a whole lot in the weight aspect of OK maybe I see myself getting fatter If I have no clue on how to lose weight a mirror doesn t do shit for me Whereas if I have guide post that say like Hey here are some rules Don t consume more than 1 200 calories a day Don t eat after whatever those commitment posts are I rely on them and I start to lose weight now maybe the mirror becomes a better tool for me to say Hey I see myself bulging back up again Now I know maybe I need to go back to those commitment posts So I think doing it the opposite way is just a much longer more painful way of doing things Clayton I think this is a funny little anecdote that cuts both ways I can imagine lots of different ways that I could probably stand in front of the mirror and make myself look different You still have to perceive it somehow This is kind of an open ended question and it links to somewhere The question is when do you use Agile methodologies and techniques like Scrum I think a lot of organizations may be going back to the trends of 2011 A lot of them say We have a supper project and Agile is going to make us go faster so we re going to use that What are some ways that may be a better way we can think about when should I apply some of these methodologies and maybe when should I not Roy That s a tough one to give a blanket answer for Clayton It depends Roy I think some examples of situations in which you can use an Agile methodology like Scrum or Lean but it becomes very difficult is when you get into areas where there are strict compliance regulations like if you re trying to do HIPAA compliance or if you re trying to do FDA ones or anything like that Then it gets very difficult because a lot of times those compliance regulations require a lot of up front documentation and you have to get that approved or they could potentially turn it down If you re doing that as you go you might end up wasting a lot investment money producing a product that gets turned down by the FDA when you could have caught that at the documentation stage Derek For me I would say Agile methodologies could be used any time you ve got a team of two or more people They re really principles and values for how you work with other human beings I think that s vital regardless of what type of work you re doing As far as an implementation i e Scrum or Kanban or et cetera I think that s really going to depend on what kind of product you re trying to deliver what kind of project it is and what things are important for success in that I think the core methodologies apply to any kind of team Currently today we re doing it inside of school districts We re not doing Scrum but we re applying a lot of these self organization techniques and really even pushing it down to empower the students in the classroom to do retrospectives with their teachers and get them more involved I think the principles go pretty much anywhere you ve got groups of people Clayton This next one is a good Scrum question there s actually two things inside It says Am I nuts to invest in specialization where I get the idea that Scrum is generalizing the team Two things Is Scrum really generalizing the team And then assuming it is should you invest in specializing in

    Original URL path: http://integrumtech.com/2012/01/scrumcast-43-taking-to-the-twitters/ (2016-04-26)
    Open archived version from archive

  • Roy van de Water Phoenix Scrum User's Group Oct 2011 - Integrum
    Cancel reply Your email address will not be published Comment Name Email Website About the author Clayton Lengel Zigich Autodidact While Agile teams find that a high trust environment is key to their success they often ignore the most important aspect a shared sense of vulnerability claytonlz Subscribe to the blog Get inspired with an Agile Weekly Podcast Derek Clayton and Chris slowly remember what they were talking about Oh

    Original URL path: http://integrumtech.com/2011/11/roy-van-de-water-phoenix-scrum-users-group-oct-2011/ (2016-04-26)
    Open archived version from archive

  • Integrum Hosts First Air Hockey Throwdown - Challenges the World - Integrum
    minute game ended with a 7 goal deficit for redPear Match tied 1 1 To settle this thing the founders of these two companies stepped up to the table to do battle redPear s Brandon Willey vs Integrum s Jade Meskill Back and forth for five minutes Brandon scored 2 goals for redPear while Jade put 5 on the board for Integrum With Team Integrum victorious Team redPear left vowing revenge Now for the fun part Integrum isn t going to sit back and celebrate our victory We re ready for anyone else who thinks they have the skills and the courage to face our team We re looking at your Open Rain Jumpbox Tornado and anyone else who dares to challenge the champions Call us out on Twitter or email we ll be ready for it All photos courtesy of James Archer from Forty See more at his Flickr Page The SPAMly Cup donated by the lovely and talented Luz PREVIOUS Valley Metro Testimonial NEXT How to run Rcov in the Ruby on Rails vendor directory 4 thoughts on Integrum Hosts First Air Hockey Throwdown Challenges the World krystofer says March 5 2009 at 3 59 pm A warning to those who would challenge he tried to make it sound civilized but Chris Conrey will roll up and manhandle you on the air hockey table I barely walked out alive If i hadn t made him laugh with a well placed movie quote at just the right moment he was poised to decapitate me with his next shot I wish i was exaggerating Beware ye who would dare to challenge beware but seriously team redPear had a great time and integrum rocks air hockey almost as much as they rock rails which is a lot Reply Pingback Air Hockey

    Original URL path: http://integrumtech.com/2009/03/integrum-hosts-first-air-hockey-throwdown-challenges-the-world/ (2016-04-26)
    Open archived version from archive

  • Increasing Productivity and Accountability Through "Public Humiliation" - Integrum
    github to monitor our CruiseControl rb feed and make everyone instantly aware of the situation The app is a JRuby creation written by our very own Logan Barnett running on a Mac Mini outputting to a 32 LDC TV Logan will be appearing at JRubyConf which we are sponsoring this year if you would like ask him any questions And before you ask Matt Aimonetti we re creating a MacRuby version of bigboard as well Enjoy PREVIOUS Integrum and Sorenson Launch Sorenson360 iPhone Contest NEXT Ajaxful Rating for Ruby on Rails Rating or Voting One thought on Increasing Productivity and Accountability Through Public Humiliation blindgaenger says October 12 2009 at 9 46 pm I ve read about a similar approach using lava lamps Can t remember think it was in some book I was very excited to use it with our Hudson but my teammate didn t like the idea Pretty sad Reply 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

    Original URL path: http://integrumtech.com/2009/10/increasing-productivity-and-accountability-through-public-humiliation/ (2016-04-26)
    Open archived version from archive

  • Episode #124 - Automate it - Integrum
    always there You know they re going to be there If something goes wrong wouldn t you rather someone blame them than blame you That s always Roy Then you get into that whole QA developer rivalry too where you hate them because they re making you do more work You don t get to work on new stuff because they keep uncovering the crap that you wrote earlier Clayton I really like the way that some people in the QA or testing or whatever community talk about testing versus checking Those are the things that a computer can do Making sure that this algorithm works properly in these different cases or whatever I really like that idea where testing is more about heuristics and looking at How does the system function and what do I expect to happen What people perceive and is it consistent with the rest of the thing All the stuff that you actually need the human brain for Those are valuable things that people could be working on actual people Everything else really should just be automated inaudible 06 56 should be automated checking Jade You posted a really awesome article I think at the beginning of this week about a case where a company neglected to use automated deployment In this case instead of automated testing but another case where something is done repetitively and there was an opportunity for automation that wasn t taken In this case I think it ended up costing that company 465 million Clayton Some trading company right Jade Right We ll attach the article to the description but it was pretty crazy They break down exactly what happened and it ends up being We just didn t automate something that should have been automated Now it s human error that comes into play Derek I see some funniness in that one of the things that had come up in some the discussions today too was Well one of the things that QA is really incredible for is our business rules are so complex that nobody understands them Literally nobody actually understands the business rule The great thing is what we do is we have QA what would happen is you would basically code the story as a developer and as you code the story as a developer my fantastic test plan is going to cover every edge case so that I can actually tell you how you didn t understand the business rule When I think about that it sets the fallacy that this stuff is so difficult that we re going to have humans try to remember how it works Like I m a human I know that doesn t work Clayton That sounds like the exact opposite of how it should be Roy Right where if it s super complicated and you ve got this thing shouldn t you have the computer be checking that it s the right thing Then make it happen faster so that I can get immediate feedback That s what I was kind of saying is The problem is that if I go and I code this thing up and it takes me five minutes and I hand it to you to run your test plan and it takes you two days to give me feedback that s really irritating What if I could run a 10 minute build and get that feedback immediately and make an adjustment That s when it just blew up into It s impossible that you could ever have a 10 minute build I think the second part I think that the thing was Great if we really automate that stuff what happens to us as a manual test team We re still going to have to do a bunch of stuff I think if we look at some of the best companies in the world that are really doing continuous deployment well they re not having manual testers test They re having real users test When they deploy something they deploy it to a small set of people or to a small set of systems run tests on them and continue to get feedback and continue to let things deploy as they get more and more feedback I think in order to be competitive especially in the kind of high tech space you ve got to get to the point where your crap s automated man I just can t see hanging with the big dogs if you re sitting out having manual tests I just don t think it s reasonable anymore Jade There s actually a ton of freedom and liberation in having those things automated right Roy Sure Jade There s no need to have human slaves that are doing that I ve been reading a lot of Buckminster Fuller and he talks a lot about freeing the human race from being muscle reflex machines That s what computers should do for us They should free us from having to worry about those types of details and those repetitive motions that can be fully 100 percent automated Roy Many of those QA people are valuable people that could be contributing so much more than just a menial task Jade Right than following a script and clicking buttons Derek One of the things I kind of brought up is that in many instances the QA people have the largest amount of domain knowledge in the company They could be the front and centre of helping to find the product and helping work with customers because they re the ones that understand the product most intimately Instead of putting them out there helping them make the product better because of their understanding of the product Instead we have them doing the menial labor of kind of like sweeping the shop floor every night which is just ridiculous Clayton I think one thing maybe we re glassing over a bit is if you already have

    Original URL path: http://integrumtech.com/2013/10/episode-124-automate/ (2016-04-26)
    Open archived version from archive



  •