All of us agree that to become a successful Application development/IT organization, we need to get more closer to business...Recently, we experimented with one of our folks from Application Development working with our business for 3 months. The insights she had into their business process, how our current products are helping/hindering the business, what are the gaps in our IT systems & support etc. were very valuable. In this case she worked in the business team as one of them. She did everything a business person would do for those 3 months.This also gives an opportunity for IT to take some of our processes to add value to business. For example, she is planning to recommend to business to do Retrospectives at the end of their each peak business cycle. Probably IT can help facilitate the first time. Wouldn't that be great for any firm to have business and IT that closer? My dream is to have business adopt an agile/lean process like Scrum or Kanban for their day to day work.Anyway, I think we should aggressively pursue more similar opportunities for our Business Analysts/Product Owners and others to work with business, and also have some business folks work in IT for a short duration (ideally 3 months time box). That way we would know first hand the current pains business have, and try to solve them. While doing that, business can learn some of the good IT practices as well...Have you tried anything like this in your organization?
Mike Verdon’s Python Twitter Tools is an awesome twitter library. It is less than 100 lines of code, and is very well commented. It uses the dynamic language features and creates the methods on the fly and returns the python dictionary. The best part: It is dynamic and creates methods on the fly. So there is no need for any documentation beyond the standard twitter API documentation pbwiki. Use the url patterns after `/` as the object parameters by separating them by a `.`. There is a global constants file that has a list of all methods that must be a POST and it makes post requests for those and get requests for the rest. Infact the author has even written a documentation scrapper that parses the twitter documentation to find out which methods are POST.* Using it is very simple and pretty straightforward. #Instantiation: from twitter import Twitter t = Twitter() #Public Timeline? t.statuses.public_timeline() Jerod Santo showed how using a ruby twitter gem library, he was able to find the people not following you back in twitter in less than 15 lines of code. A perl guy demonstrated to do the same in the Zen Perl library. So how many lines of code would it take using the library that I think is the best across all languages. Lets try out. Finding Friends ids? From the twitter API wiki: URL = http://twitter.com/friends/ids.format Thus, our method for finding the friends of a given user will be t.friends.ids(screen_name='becomingguru') and thus the entire code to print all those the user follows but who is inturn not followed back is as follows: import wrapper ts = wrapper.Twitter() user = 'scorpion032' diff= set(ts.friends.ids(screen_name=user)) - set(ts.followers.ids(screen_name=user)) for i in diff: try: non_fol1 = ts.users.show(id=i) except: continue print "%s with %d followers and %d following" %(non_fol1['name'],non_fol1['followers_count'],non_fol1['friends_count']) *However this auto updating of POST functions is yet to be updated as the documentation format got changed, recently after @dougw joined.
Deep in my heart it pains..nothing like joy remains..all I feel is ultimate despair,tearful eyes are occasional if not rare..I tried everything to make it work,they laughed at me and said I was a jerk,even to think that my efforts would succeed,I was only as good as a second lead...looks like mine don't catch the eye,I do not register, any more than a passer by,so what if my heart is of gold,so what if its filled to the rim, with love for him many fold..and just when I was sulking and sinking so low,i saw him coming, his face aglow,the passionate gleam in his eyes, that I always searched,stopped right in my front why? I wondered..he was talking to me, I couldn't believe,I am always in his thoughts and do not leave,the sparkle of my eyes, is what he can't forget,if he wont say it now, he will always regret..I am a person of substance,its what he liked,he said i was BEAUTIFUL,and just then..i BEAUTIFIED....
This is the second of my series on the values we believe as an Application Development organization...Let me start by defining what sponsors mean for us. As an AppDev organization, sponsors come to us with Application Development projects and we execute those projects so that we add value to the business. In our case most of them are internal clients. To take us to excellence in software development, we need to consistently exceed those sponsor expectation, so that they come back to us all the time happily, and never think of developing an application without us. As my colleague Mark puts it “Do your sponsors ask you to run an airline?” (He was referring to the zappos.com video on Nightline). We need to get to a state where our sponsors love us that much so that they ask us to run an airline. I know its hard .. but possible.In the past (from my PMP days) exceeding sponsor expectation was all about delivering on time and on budget. Those days have gone for us. With the help of Scrum and timeboxed releases most of our projects are expected to be on time on budget. But then what is that matters? Is that scope? Not exactly… (1) setting the right scope, (2) sticking to commitments and (3) proper communication are the three things that are going to matter the most.(1) Since scope is the only variable in the iron triangle how do we deal with it so that we exceed sponsor expectations? Its simple! Start with having a short vision for the time-boxed release by defining what business value are we going to deliver in the three months. If the project takes more than three months, break into smaller three month chunks. Make sure the stories (requirements) are prioritized to delight our users and aligned to the vision. Do release planning and tell sponsors what is possible and what is not possible in that release upfront based on the teams velocity. Understand what success criteria looks like for them. If it is not achievable, set the expectations upfront.(2) Once you set the right expectation upfront, communicate... communicate... communicate! Scrum gives the framework for doing that. Doing Release planning, Sprint planning, daily stand-ups and sprint retrospectives the right way are key to this. Try to get time commitment from business so that they are available for the team when questions arise. I would recommend having them as part of the Product Owner team wherever possible. Similarly understanding and communicating risks are key as well.Remember we are a service organization. We can never say “No, we can’t do it!”, or we can always say "Yes we can do it!". Instead, understand what they want and offer options so that it’s a win-win situation for everyone. Agile development gives a lot of flexibility to do this. Another important factor for success is to educate them when required. For example, if they are not aware of the benefits of automated testing, explain to them that... if they have an urgent change that needs to be done in a day, these automated tests can help them do that the same day, whereas manual testing would take few days. They will be convinced if we show them the benefits other projects have got from these kind of practices that is required for delivering quality applications.(3) Once the team commits, it is important that we deliver most of the time. If we commit and don’t deliver, they will slowly lose trust in us. If its hard to commit due to lot of unknowns, we have to let them know that we need some more time to get more information before committing the deliverables.Above all, what matters the most is how the team interacts with sponsors when things don’t go so well. We have to remember that every interaction is an opportunity. We can never keep them on the dark. Letting them know the bad news early and having different options or workarounds upfront would make a big difference in such situations.These are simple things most of us know. We need to do this in every project so that we consistently exceed sponsor expectations. What are your thoughts on this?