I will not stretch the analogy of jugglers juggling and engineering teams engineering too far. In brief, software and system engineering teams can benefit from working on a few things simultaneously but too many or too few can cause everything to fall apart. ...
There has been a dearth of posts to this site. Part of the reason for this is that I got busy playing Overwatch by Blizzard. The underlying mechanics of the game are team based and players must work together to achieve success. Failures in the game are often due to players not working together effectively. These sorts of failures can have lessons for teams working on projects in a professional capacity; today we’ll look at a couple of team failure modes and consider ways they can be rectified. ...
Today’s post will cover a couple different approaches to transfering techinical knowledge of a software system between individuals or teams. There are often transfers of ownership as a software product progresses from conception to feature development to ongoing maintainence. Effective knowledge transfers between owning individuals or teams help to ensure that ongoing development of a product is not totally stalled whenever ownership chagnes ...
Developing new software involves resolving a frequently unknown quantity of problems of unknown complexity. Even when working on existing projects, new initiatives and features can contain a unknown total amount of complexity. While being appealing modern product management methods, scrum and other related methodologies focus on relative estimation which has limitations when starting brand new work. Today’s post looks at some of our limitations when it comes to estimation and what is implied by those limits. ...
IT consulting is an odd place to be when it comes to software engineering practices. We often end up writing software for business groups that have fixed budgets and more importantly fixed deadlines. We also try to follow an agile methodology for software development that roughly follows scrum (warning: PDF), but with defined roles for a project manager and a development lead. Today’s post discusses some of the difficulties seen in using Agile to deliver business software and how we can mitigate those difficulties, basically things that worked and things that didn’t. ...
Being an IT consultant has occasionally had me working in unusual or cramped quarters at client offices, the result of being hired help instead of a full time employee. One type of psychical situation I have ended up working in a few times is something we called “the project war room.” ...
I just wrapped up working on a month long project planning phase with a new customer. We gathered user stories, made technology selections, built proofs of concept, and generally got to know the customer’s business. What was interesting about this planning phase was that we started with a detailed product specification and worked backwards to define user stories and acceptance criteria for the project. While at first this may seem like a waste of time, it was actually extremely valuable to all parties involved. ...
One of the hardest parts about building software for people is the people. The last couple projects I have worked on have been user oriented data exploration tools (generally speaking, one was for a marketing group and the other was for an automotive firm). In both cases there were two overarching questions that had to be answered for every feature we implemented. The questions were what would a new feature do and how would a user use the new feature. In a version of form over function we discovered that a number of times how a user would use a feature to find data would influence how it needed to be implemented. ...