Archive for the ‘Agile Development’ Category

Multitasking, good or bad?

We have all heard that some people are better at multitasking then others. My question is; does multitasking help a person complete project tasks successfully in the total time allowed for those tasks? Besides having multiple tasks to complete, there are also phone calls, IMs, emails, meetings and other interruptions that are relatively constant throughout a Project Manager’s typical day.

One habit that most of us face, throughout our lives, is losing focus. Once you are able to consistently focus on one task at a time it will then become easier to conquer this habit. Some things that can help you to stay focused are prioritize tasks, address one task at a time and keep the tasks small. Keeping a task small may involve breaking a large task down to several sequenced smaller tasks. If a critical task surfaces, address it and then go back to the task that you were working on prior to the critical task. If there is an interruption, try and schedule it for a later time, ignore it or keep it to a minimum.

I found the following link interesting on how to identify “bad multitasking” and ways to avoid it. Along with the tips is a podcast.

http://pm411.org/2009/09/29/podcast-episode-047-schedule-killers-bad-multitasking/

Podcast episode 047: schedule killers – bad multitasking September 29, 2009 By Ron Holohan, MBA PMP

Tags: , , , , ,

This entry was posted on Monday, August 22nd, 2011 at 8:58 am and is filed under Agile Development, IT Professional Services, Leadership, Project Management, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

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: , , , , , , , , , , , ,

This entry was posted on Sunday, April 24th, 2011 at 2:08 pm and is filed under Agile Development, Business Drivers, Entrepreneur, IT Professional Services, Project Management, Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

An 8 Step Program for Recovering Micromanagers Like Me

Getting peak performance from a great project team is no mean feat. What can make the challenge particularly intense is a senior and seasoned team, combined with a complex project that requires large amounts of interaction and communication to coordinate effectively. For those PM’s highly skilled in the art of ruthless task management and no holds barred follow-up, it is not hard to let diligent and very necessary pursuit of closure outcomes slip into annoying and counterproductive micromanagement.

Why is this especially a concern with more senior teams? Because many senior people are often much better able to rise to the occasion of contributing to solving hard problems when the team environment both allows and encourages them to do so; and they are often the most likely to get bent out of shape and experience falling productivity when their manager starts to give detailed input on how to spend each minute of day.

I saw a recent blog post that was nicely on point to this issue, from the PM Alliance. I excerpt it below, but the slightly longer piece is worth the read as well here.

Credit: iStockPhoto.com

——————

8 Ways to Banish Your Inner Micromanager

By PM Alliance President, April 2, 2011

1 – Stop hovering. If you find yourself peering over a teammate’s shoulder, step back …

2 – Ask fewer questions. That’s right—instead of assuming that you need to request every bit of data you want, you should be relying on your team to keep you informed proactively [and holding them accountable for doing so]…

3 – Delegate more. Micromanagers are famous for giving tasks away without ever really letting go, and sometimes for not giving tasks away at all…

4 – Stick to working hours. Some projects require overtime, but constantly pulling employees’ brains back to work after they’ve gone home is just a variation of hovering…

5 – Empower your team. Are your employees forced to seek approval for every decision, from the big stuff all the way down to day-to-day minutiae? Set up a process that instills responsibility and grants authority based on each staff member’s seniority and experience.

6 – Watch your temper. Getting overly upset or losing your cool with employees is a classic sign of a micromanager. It frequently leads to hovering and incessant questioning, both of which you want to avoid. When you feel something isn’t going well, stop. Take a minute, gather your composure…

7 – Take mistakes in stride. Glitches are the siren song of the micromanager—they make it easy to doubt your team’s abilities, assume you have to do everything yourself, and generally make life miserable for those around you. Remember that mistakes happen to the best of us…

8 – Don’t let your boss bring you down. If your boss is a micromanager (or perhaps just a difficult personality), you may find yourself offloading stress by funneling your frustration and anger into your team. It’s a tough position to be in, but you somehow need to separate the way you’re being treated from how you treat your team…

 

As I said at the start, this is just an excerpt; the whole article is worth reading at: http://it.toolbox.com/blogs/project-management-tips/8-ways-to-banish-your-inner-micromanager-45275 BTW, the PMAlliance, Inc. is a project management consulting, project management training and project office development company that helps Fortune 1000 companies improve the execution of their mission-critical projects.

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

This entry was posted on Friday, April 15th, 2011 at 3:30 pm and is filed under Agile Development, IT Professional Services, Leadership, Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

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: , , , , , , , , ,

This entry was posted on Monday, November 15th, 2010 at 8:49 am and is filed under Agile Development, Business Drivers, Project Management, Technology, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

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: , , , ,

This entry was posted on Tuesday, October 19th, 2010 at 2:27 pm and is filed under Agile Development, Leadership, Project Management, Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Microsoft Releases Security Guidelines for Agile

security-report

Microsoft will release guidelines for developers building online applications and for those utilizing the Agile code-development process.

The Agile guidelines apply principles from Microsoft’s Security Development Lifecycle (SDL) to Agile, an umbrella term for a development model frequently used for Web-based applications released under short deadlines, called “sprints.”

Microsoft adopted the SDL following the company’s pledge in 2002 to build more secure code after several high-profile worms and other malicious software posed dangerous risks to its customers.

But the original SDL doesn’t fit the Agile process. Agile differs in that developers have a set time in which to develop certain features, after which the application is immediately released in order to get customer feedback, said Bryan Sullivan, security program manager for Microsoft.

The SDL was originally designed for products, such as the Windows OS, that are non-iterative, meaning that there aren’t frequent releases of the product that add just a feature or two. However, all of the SDL requirements have been adopted for the Agile process, but implemented differently, Sullivan said. Agile is used by 85 percent of technology industry professionals, according to Forrester.

Microsoft breaks the SDL down into three requirements: one-time only tasks, those that need to be done for every sprint, and finally “bucket” tasks, which need to be repeated periodically — such as every six months — but not for every sprint, Sullivan said. The Agile guidelines will be available on Tuesday on www.microsoft.com.

Microsoft is also releasing a white paper on security for online Web applications. As those applications are increasingly interacting and exchanging information, security is paramount, said Steve Lipner, senior director of security engineering at Microsoft’s Trustworthy Computing Group.

The white paper outlines key security issues that developers should consider for Web applications, Lipner said. It also discusses security issues that developers should think about when choosing a hosting provider, such as data and physical security.

Copyright 2009 IDG News Service, International Data Group Inc. All rights reserved.

To read more, click here.

Tags: , , , ,

This entry was posted on Sunday, November 29th, 2009 at 3:30 pm and is filed under Agile Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Understanding the Customer vs Customer Value

24kt_Gold-Plated_Macbook_Pro_Laptop1[2]

It is often claimed that Agile software development is flawed because it focuses on improving the processes of the team developing the software;  is that really a bad thing. But there is a difference between understanding the customer and focusing on delivering customer values. Agile methods don’t allow for specific improvements to be focused on, as a result the developer doesn’t see the minimum that is required, but rather goes for the less cost effective ‘gold plated’ option.

To read more, click here.

- Michael Grollman

Tags: , , ,

This entry was posted on Monday, November 9th, 2009 at 2:17 pm and is filed under Agile Development, Business Drivers. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Open & Agile

Like most I think I am a fan of all things open (it sounds better than closed) the term “OpenAgile” recently caught my eye.  The group pushing this term has a nice e-book pdf of their concept.

One of the people out in front on this is Mishkin Berteig. He seems to be combing some Scrum stuff, some Lean stuff, and something called the Learning Circle from the education world.  Other than having the e-book out there, I am not sure what is “open” about it, but the e-book is a quick read, and may prove useful to teams trying to find a form a Agile that works for them well.

- Michael Grollman

Tags: ,

This entry was posted on Thursday, August 20th, 2009 at 9:26 am and is filed under Agile Development, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Taking Scrum up a Notch with Smoother Agile

John Scumniotales , the co-creator of Scrum and the first Scrum Master (his words) did a really cool webinar on why agile environments needs more than Scrum.  Among other things, he lays out four key elements that are part of securing a successful agile environment, none of which are really top of the list in a pure scrum philosophy although not in any way antithetical to scrum, just a layer on top of it.):

  • Cross-functional teams that include the customer (or their proxy), development, test, documentation and anyone else required to create “the whole product”;
  • Incremental delivery of production quality capabilities at regular intervals;
  • Test-driven development that builds quality in from the beginning;
  • Automated and unattended build, test and reporting and I maniacal focus on build quality.

I particularly like the test driven development stuff.  You can check out the whole webinar here.

- Michael Grollman

Tags: ,

This entry was posted on Thursday, August 20th, 2009 at 9:25 am and is filed under Agile Development, Entrepreneur, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Getting performance measurements right in Agile environments

One of the hardest things to do in any agile development environment is the production of good metrics on productivity.  Jeff McKenna, one of the earliest leaders in agile development, put out a blog entry on just this point.  A key issue, Jeff points out, is that at all development varmints are based on team dynamics, and it is always difficult to separate out team productivity from individual productivity.

He suggests the following rule of thumb to help build evaluation and performance systems for ads all environments.

To summarize:
50% Team performance
25% Team evaluation
25% Individual growth in functional area

Read more here.

- Michael Grollman

Tags: ,

This entry was posted on Thursday, August 20th, 2009 at 9:22 am and is filed under Agile Development, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.