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 #98 - Storming Teams - Integrum
    someone that is afraid of conflict or has more traditional mindsets is going to put the brakes on and want to hold off That s probably the wrong thing to do right Derek Yeah I think it was interesting because this team happens to be doing scrum they believe they re doing scrum I would say they re not really doing scrum but they do have a scrum master Clayton So they re doing scrum right Derek Yeah I believe that the scrum master knew this behavior was not kosher was counterproductive but they had nothing in their toolkit to say I m going to prevent you from going off and doing this crazy thing and redoing the planning meeting all by yourself in the vacuum and delivering a PMP level schedule back for when things are going to be done and who s going to do them and everything else They knew that was totally wrong but they didn t know how to deal with the person The best that they could do is say OK Well if you re going to do that then I m going to hold you hell or high water to that schedule and if you re one minute off from that schedule this is going to be how I m going to say That s why we don t do it that way which is not necessarily a good response It was nice that they didn t just dig their feet in and say We re not going to try to improve because somebody on the team has got a problem with it At the same time one of the things that s difficult about change is if you do not have people around that know how to deal with change and with personalities you just say Hey yeah we still want to change but I don t know how do we tell him no Roy How can you tell a change is good change or bad change Derek The upper management team when they heard this was happening I think their initial thing was Do we need to fire the person I was like Whoa whoa whoa That sets all sorts of bad precedents you go against what somebody wants and that means you get fired That s not the culture you want either At the team level it s Nobody has ever told this guy no before so how do we do that Clayton Do you think that if you were a scrum team that was doing more traditional scrum and you re having your retrospectives I would assume that that s the kind of thing that would come out in the retrospective about that behavior What do you think led to this going on for so long Roy Not knowing much about the situation other than what we ve briefly talked about in this podcast my guess would be that the retrospectives don t feel like a very safe environment to bring this type of stuff up Either retrospectives aren t frequent or not happening or when the retrospectives are happening nobody feels like they are in a safe environment where they can bring up anything like this without getting totally shot down Derek I suspect that more than anything the retrospectives are probably a little bit shallow I ve only seen half of the retrospectives that this team has done so I can t really speak to it But it definitely seemed like a fairly shallow sounding bored and disinterested Hey does anybody have anything we want to improve OK Do you have anything you want to change OK Not a whole lot of techniques used to provide safety to people I don t think there was necessarily any kind of hostile environment during that but I don t think that there were the typical tools that a good facilitator would use to try to deal with some of these problems One of the other things is it s just the way that they work People don t think Hey maybe we would change this or Hey this could be different Roy Instead of abiding and perceiving that there s a problem Derek A great example is during their planning meeting this particular individual was not there They were tasking some stuff out and it came down to We can t task this out because so and so is not here It was great because their manager said What do we do I said Why can only one person do this Ultimately their manager really pushed them and said So you re not capable Clayton of doing a database change Clayton said No I am He said Then why can t you task it out Well because Roy says that we re not allowed to do that Only he s allowed to do that Roy This is true by the way laughs Derek The manager says Well I don t care If you re capable of doing that I trust you to do it Task it out The look on that developer s face is shocked Oh wow I m allowed to do that They wouldn t even think to question it I think we forget how programmed people get where it s Well that s not my job That s someone else s job When it comes to retrospective I m not thinking How can I get Roy s job so that I can do database work Clayton Let s just say that s the culture The men go out and hunt and it s Could a woman go along and hunt too Probably but that s not what they do That s not how the culture works so that s crazy to even promote suggest that idea Roy We see this all the time with QA people Man that QA person touches code like Ooh They might fully know how to do some automation They might already

    Original URL path: http://integrumtech.com/2013/02/episode-98-storming-teams/ (2016-04-26)
    Open archived version from archive


  • Episode #49 - Topic Smorgasbord - Integrum
    of model is the team that not only directly approaches but actively solves the problem right So it s one thing to say Hey you re really pissing me off in ABC it s another things to say Hey how do we get to the point where we re including you in the team better So with that I am sticking with the team concept I ve seen a lot of organizations that are undergoing change and wanting to go to self organizing where they ve got a team that maybe isn t performing up to par They ve done command and control and so they try to go to something that s like a hybrid command control Maybe it s self organizing with all sort of reporting structures back or status reporting mechanisms They tend to flip flop back and forth between giving the team full reins or enough rope to hang themselves to completely command and control and ultimately they re just afraid that products are not going to be shipped on time or they re not going to be successful What are some key triggers you see in that and if you re a manager in that situation how do you get to the point where you let the team be self organizing and still mitigate whatever risk you re kind of concerned with Jade I think again it goes back to some simple rules of engagement If I were to look at that situation that you re talking about I d say there s probably some lack of trust happening there probably for various different reasons Either people aren t doing what they say they re going to do and so the command and control sneaks back in There s a lot of reasons that you can see that kind of flip flopping around Kind of trying to sort of self organize I think the trick with self organization is kind of an all in mentality You have to give them the container to self organize within or else they re really not self organized Your job as a manager is to figure out what that can look like and at the same time help you team to not drive off a cliff It s a tough balance to find Derek So I really like a blog post that was on Jeff Sutherland s blog called The Scrum Shock Treatment It was describing a way to jump a team into the idea of doing Scrum It was very command and control which is the part I didn t like but it kind of made sense in this context which is I m going to tell you how Scrum is going to work and we re going to do strict Scrum and you guys don t get a say in the matter until these criteria are met He had some arbitrary criteria which I think you should probably negotiate for specific cases like whenever you have more than 240 percent of your current velocity or things like that Then as soon as those criteria are met then we re going to slowly start to allow you to make more decisions because I think that s one thing that I ve seen a lot where a team starts doing Scrum but then starts making their own exceptions to the rules before they understand why the rules are there in the first place And before they can understand why the rules are there in the first place they have to see those rules in action and see how effective they can be I think Jade you pointed out earlier that you re coaching a Scrum team and you saw them doing the almost traditional like Let s start cutting ceremonies because they produce too much overhead Jade Yeah the wand of Scrum Derek Right Then it s the inevitable Let s start replacing all of our physical tools with digital ones because that would just make things so much better I think that those are the types of things that we really need to get them to try doing the things the right way first and then let them change things up and make their own decisions Clayton I think all the Lean Kanban people just collectively face palms at the Scrum Shock article But with that said I think an important thing if you re a manager dealing with self organizing teams is to really make that clear distinction about self directing versus self organizing You should never say self organizing without mentioning self directing as well But assuming you can get that in place where you have some constraints I think then you can switch into the role of rather than being either the taskmaster or the tweaker or nitpicker person who s just constantly looking for whose shoulder can I look over that kind of thing to be more of the enabler person who s saying What s my team missing and how can I enable them to be successful I think that s an important distinction to make There s probably some argument to be made for letting the team self organize and maybe a certain regard to get going Then as they become more comfortable in that space they expand in that I think over the life of the team that box probably gets bigger and bigger and bigger until it gets to a point where the box is no longer important But starting out I think you could probably let them self organize on smaller things first I think with that said though there s probably never a good time to just say Now we re a self organizing team There s always some impending release or something that s coming up that s going to Oh we can t do it now If we waited six months then it would be a perfect time And that time never comes So you really

    Original URL path: http://integrumtech.com/2012/03/scrumcast-49-topic-smorgasbord/ (2016-04-26)
    Open archived version from archive

  • Episode #30 - Leadership and Finding Them On Your Team - Integrum
    self organizing a team is the less important the leader is Leaders are willing to take responsibility for the team PREVIOUS Special Episode Keith Denham Phoenix Scrum User s Group Sept 2011 NEXT Episode 31 White Elephant Estimating 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

    Original URL path: http://integrumtech.com/2011/10/scrumcast-30-leadership-and-finding-them-on-your-team/ (2016-04-26)
    Open archived version from archive

  • Calling all Rails Nerds! - Integrum
    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 our spirit to succeed Subscribe to the blog Get inspired with an Agile Weekly Podcast Derek Clayton and Chris slowly remember what they were talking about Oh ya Culture Fit Including mono cultures hiring diversity of

    Original URL path: http://integrumtech.com/2009/02/calling-all-rails-nerds/ (2016-04-26)
    Open archived version from archive

  • To Eager Load or Not Eager Load.. Is That The Question? - Integrum
    you are unnecessarily using eager loading We have started to use Bullet in development and staging environments It even supports Growl PREVIOUS Analyze MySQL Queries Index Optimization NEXT Testing Multiple Versions of Internet Explorer Step up to the mic Cancel reply Your email address will not be published Comment Name Email Website About the author Crew Subscribe to the blog Get inspired with an Agile Weekly Podcast Derek Clayton and

    Original URL path: http://integrumtech.com/2009/12/to-eager-load-or-not-eager-load-is-that-the-question/ (2016-04-26)
    Open archived version from archive

  • Episode #03 - Agile Estimations - Integrum
    s something I find very interesting that people treat estimates like estimates and guesses in the beginning and then when it comes time to do the actual project they think that the estimates are non negotiable Somehow if they don t perform or they don t get the velocity done what they thought it was in the estimation process now that they ve talked to the customer they feel like they re going to be chastised for that I think that s pretty fascinating Derek I m curious What do you think it is in people that makes them have that change I think one of the beauties is in doing each of the pieces in isolation you really don t think of it necessarily as a commitment You re really being true to it being an estimate When that project goes live and the switch is flipped so to speak there definitely is that panic that reality moment How do you think developers can overcome that initial sprints panic moment looking at a velocity and not letting it paralyze them and instead let them gauge an accurate velocity for the project going forward Clayton I certainly think that a lot of that just comes down to when the project starts or maybe they have the initial planning meeting with their customer they just need to be realistic about what everyone s expectations are Maybe if you re a little kid and you get in trouble or you do something wrong and you re waiting for your parents to come home and you re freaking out about how terrible it s going to be and you make such a huge deal out of it When in reality it gets to as long as you re honest about it it s never as big of a deal as you thought Same thing with the projects they start out and everyone panics and they get paralyzed When you have that conversation and you talk about expectations and then you realize the s sign of velocity was this But now that we have had this conversation we ve talked about it for a little bit I can see that some of these stories are more complex or at least the scale of complexity is a little bit different We re going to need to have a conversation about how that affects the velocity in the project et cetera et cetera People don t ever get to that point The developers typically get to a point of paralysis and then they start making excuses They forget all about the fact that they estimated these stories and they were happy with the estimates and now it s Oh God I m on the line for this I better do something about it I don t know what I m going to do It s not my fault The estimates are bad Their excuses start coming at that point Derek I find it interesting that usually

    Original URL path: http://integrumtech.com/2010/01/scrumcast-3-agile-estimations/ (2016-04-26)
    Open archived version from archive

  • Episode #94 - Agile Design and UX - Integrum
    t as comfortable then we just pair them up with one of our front end developers so that they can really work day to day throughout the day on this task of creating the prototype Jade What s like transition period been for you guys in making this change Is it something that you were able to pick up pretty quickly or has it been a few months that you ve been learning as you go or what s that been like Kevin It s been a constant evolution In some ways I want to say going back 15 years when I started doing design work because you re always in the process of designing the design process if that makes any sense Jade Sure yeah Kevin I say with pen sketching we ve really been getting back into it It was really a part of my early training coming out of industrial design There s a culture of sketching in industrial design and then of course there s whole lot of years where I used only digital tools and now with the team that we built at indecipherable 07 47 drive which is relatively new we re really looking for new ways to collaborate when we started to pen sketch more it really gelled and it was very quick Clayton What do you think is the biggest contrast that you see between moving towards this new maybe more agile direction versus the old way that you did things the more waterfall lot more hand off and more formality around that Kevin The contrast between them Clayton Yeah Kevin Without sounding like a bunch of hype I think the more agile processes in pen sketching in this collaboration that we re talking about creates better ideas quicker It really allows you to generate a lot more ideas so therefore find the bad ideas more quickly and invest your time into the good ideas more quickly Jade Why do you think it allows you to do that Kevin The pen sketches no matter what specifically looks sketchy It s just so fast you can t get bogged down in pixel pushing even if you re doing what we call Greybox wireframes which are very low fidelity wireframes If you re in OmniGraffle you inevitably just end up spending a lot of time trying to figure out how to invert an object you have to search in through help and menus If it s a pen sketch you re going to just sketch that in a few seconds and be done with it Clayton You re not as tied to the concreteness that a digital tool might give you Kevin Yeah Clayton Some of that formality of presenting it to your customer and having them review it all that stuff tends to add overhead and really changes the interaction that you have Kevin Totally changes the interaction With pen sketches they never confuse the sketch with something that might be final and

    Original URL path: http://integrumtech.com/2013/01/episode-94-agile-design-and-ux/ (2016-04-26)
    Open archived version from archive

  • Episode #17 - The Cost of Change - Integrum
    much more honest much more true outside of the performance review and then fill out whatever performance review is necessary to turn into HR to placate them and congruently be trying to get HR to change their practice so that they re more in line with being an Agile organization as opposed to being the dinosaur organization Clayton I agree with what you re saying Derek but I also think that we do need to have some mechanism of dealing with the individual as well There are a lot of ramifications that a poorly performing or a bad fit can have on the whole team So creating those mechanisms that can deal with the individual behavior and I think tailoring the reviews and the feedback to the very specific individual person at that level is good as long as you are also dealing with like you said more of the team context as well I think somewhere is a balance between those two aspects You can t completely forsake the individual for the team or vice versa Derek So I think to me where the problem comes in is that most performance reviews are structured towards the skill that you do and I think that s a bad way to do it So if you re monitoring me for how good of a software developer I am and it has to do with the amount of code I m producing or the number of commits and I don t want to say necessary metrics but things related specifically to code I don t know if that s a good representation of whether I m a good individual for this team I think it s Tom Lister One of the things that they did when they looked at a number of teams in writing their book PeopleWare is they asked Who do you want to be on your team and why did you want that person to be on your team In almost every organization there was at least one person that was on every single successful project and that when asked they were deemed one of the most valuable people on each one of those projects Derek But when they asked the people why nobody could put their finger on it I think what starts to happen is if you have a review that is simply a skill set are you good binary at this task yes or no Sometimes you rule out the best people because the best people that make teams successful are key people that make teams successful are the people that enable other people to do their best work I think that yes you do need to take things at an individual level and review somebody individually But I think we need to get to the point where we re evaluating people individually on how they adhere to the team s values and how they adhere to the team s principles not to specific skills or

    Original URL path: http://integrumtech.com/2011/06/scrumcast-17-the-cost-of-change/ (2016-04-26)
    Open archived version from archive



  •