Archive for the ‘Technology’ Category

Project Teams in Space: The Times Are Changin’ (Again)

What makes for a productive software development office environment?   How much “close” company is too much, and how much isolation and quiet is simply too much?  When is an interruption welcome and needed, and when is it a mental reboot that sets back focus by 15-30 minutes each and every time it hits?  When is management’s new ‘space plan’ about creating great teamwork, and when is it about seeing how many people can be crammed into the smallest number of square feet of costly grade A office space?

As near as I can tell, there are no absolute answers to these questions, just a a series of tradeoffs that each manager needs to evaluate in putting together a plan for how the work environment for their team best goes together.  But while there may not be final answers, there sure are fads and trends. Let me give you a hint – the trend is not heading towards more square footage per person in most places, although there is still a movement afoot to keep the noise to a dull roar in some of the more technically intense shops.  Cara Garretson of ComputerWord put together a nice piece that talks about where these trends are heading just now.  The piece is worth a look.

 

 

Cubicle wars: Best and worst office setups for tech workers

Open office layouts are all the rage these days. But is that how IT folks work best?

By Cara Garretson

ComputerWord 2011

Computerworld – Consider the modern office layout: Open floor plan, lots of common space flooded with natural light, clusters of “pods” with low partitions (or none), all designed to encourage teamwork, boost productivity and — management hopes — improve the bottom line.

That type of office layout looks great on the company’s Web site, and most likely the creative team loves it, but does IT? After all, many high-tech employees prefer to work in solitude, or at least in an environment quiet enough to foster intense concentration for significant chunks of time. Are these trendy open office layouts torture to the techie brain?

To be sure, Web 2.0 has birthed new types of technology employees who depend on — even thrive by — working in groups. Web designers and developers, project managers, system architects, even some software developers are embracing office layouts that encourage interaction. Practitioners of the Agile Software Development movement have even come up with templates for office furniture arrangements that are physical embodiments of the Agile principles of openness and collaboration (see example, below).

On the other hand, asking programmers or network administrators to do their jobs in an open space where noise, distractions and interruptions abound can be akin, for some of them at least, to departmental decimation.

 

Read all from Garretson’s  article here.

Tags: , , , , , , , , , , , ,


Check this box if you think you are exempt…

Building software is hard! There are minefields everywhere…and if you don’t get the basics right the project is going to explode. Everyone hide in the bunkers right now, because when I say ‘the basics’, the basic that is the topic of the day is TESTING. Just because the letters QA are nowhere to be seen in your job description you are not exempt from the responsibility/accountability.

Now that I have your attention, I promise no more military references. But I also promise that reading on will force a gut check of your testing awareness. Today is a re-blog and it’s an oldie but goodie. One of those that makes you laugh lightly when you read it, but deep down in your core you know most of it rings true and hints at your organization’s flaws. Its title: The Joel Test: 12 Steps to Better Code implies that that the target audience is developers…but those of us who are always on the lookout for motive know that the post was likely intended to be used as ammunition (sorry… incentive)for PMs to get budget to upgrade their defect tracking software or hire another testing resource.

More thoughts on this blog:

• Giggling at the Netscape references may date you.

• The writing style is entertaining enough that your peers will read it all the way through and so will your developers, after which they will initiate much conversation about how you can help them do their job better. Be sure to tell them that improvement takes time, and unless you are a hard-core Commercial house, a score of 8 or above on ‘The Joel Test’ is perfectly respectable for the moment.

• Each question is open to interpretation; everyone’s definition of quiet or up-to-date is different. Bottom line: if your score is lower than 6, then you now know what needs to be done!

http://www.joelonsoftware.com/articles/fog0000000043.html

 

Post your score and any related *issues* here so everyone can discuss how to improve the testing model within your organization.

Tags: , , , , , , , , ,


Successful Projects through Agile Project Management

Agile movement the “brain child” of the development world? 

by Nancy Nee.

Both traditional and agile project delivery embody similar principles and practices that aim to deliver measurable results. Traditional project delivery can be described as a “waterfall” approach, which presumes that the requirements, expectations, duration, activities and outcomes of projects can be predicted accurately and planned in a sequence before any actual development activity takes place.

In contrast with traditional project methods, agile methods emphasize the incremental delivery of working products or prototypes for client evaluation and optimization. While so-called “predictive” project management methods assume that the entire set of requirements and activities can be forecast at the beginning of the project, agile methods combine all the elements of product development, such as requirements, analysis, design, development and testing — in brief, regular iterations. Each iteration delivers a working product or prototype, and the response to that product or prototype serves as crucial input into the succeeding iterations.

Delivering “customer value” is a key aspect of agile project delivery. Agile project management is conducted through the collaboration of a small, co-located team that usually consists of the customer/end user, a project manager, a business analyst (or the role of business analysis) and specialist(s). Agile theory assumes that changes, improvements and additional features will be incorporated throughout the product development life cycle, and that change, rather than perceived as a failing of the process, is seen as an opportunity to improve the product and make it more fit for its use and business purpose.

Read the rest of this entry »

Tags: , , , ,


A PM’s long road trip to San Diego …

So when does a swamped project manager find time to write a blog… when trapped without internet on a long road trip to San Diego …

Road to San Diego

Road to San Diego

So many topics… so little time… what’s a gal to do?

I’m not really sure there’s a formal definition for the kind of project management we do.  As consulting project managers, my fellow project managers and I don’t really fall into what I would consider the standard PMI definition.  The catch phrase ‘on time, on budget’ still applies, but it’s a lot less academic and much more hands on.  We are not the types who are satisfied with high-level status updates for fancy project schedules.  We are in the trenches working with the client and the engineers to get the job done.  We are combination business analyst, user interface designer, technical writer, quality assurance specialist, business manager and fire fighter.

WE NEED TO KNOW EVERYTHING
Or at least it seems that way.  We need to know the business process, the user who will be using the system, the available technologies, the software best practices, and the technical possibilities.  I think it sometimes drives the people around us crazy, because we never stop asking questions and challenging assumptions in an effort to eliminate shades of gray and possible misunderstanding and re-work.  The possibilities are endless and there is never just one way to do something.  There isn’t even one best practice.   We have to synthesize the information from the business users and the software engineers, to make the most qualified recommendations.  And we are at our most effective when we have direct knowledge and understanding of the users who will be using the software systems.

BREAKING IT DOWN
One of the key criteria to success of any project is breaking down a large work effort into smaller bite size pieces in order to understand the dependencies (critical path), resources (people, software, time), and communication required.  My 5 year old’s favorite cartoon these days is Special Agent Oso… he’s oh sooo special.  He’s a panda bear in training to be a special agent, but his training missions are always interrupted by special missions to help kids learn how to do things.  Everything whether learning to hula hoop, play hide and seek, take the rabbit to school, or cook blueberry muffins, takes three steps to do it right.  In real life, it almost never takes just 3 steps, but the concept of breaking every task down into smaller steps helps tremendously.  Even to start writing my first blog entry… I couldn’t stop myself, I started breaking it down into possible topics.  And that part about getting interrupted for special assignments… it happens all the time.

Viva la blog… let’s see where this road trip takes us…

- Mara Pederson

August 2009

Tags: ,