Steve Tasker is one of two people on the Marketing team that distributes all email blast communications to the chapter. All email blasts are required to go out in a timely fashion. One added duty that the two volunteers have is to respond to all email inquiries about the email blasts. The questions they receive are quite varied.

 Before taking this role, any questions from our membership regarding the email blasts went unanswered which lead to member dissatisfaction. Steve has answered questions from our membership on a variety of subjects. To answer the questions, many times he would have to find the correct person in the chapter to provide insight or figure out on his own how a process worked and give the member an answer. He responds to questions in a timely manner because many are time-sensitive when they relate to registration. His role has provided a great insight into the obstacles our members encounter. Another important part of this role is to transmit the feedback to specific VP areas so that they can respond to the issue. Steve’s role has provided an effective feedback loop from our members into the chapter.

 Steve completed the Penn State Certification Program in March 2009. He joined PMINJ on 10/10/2007and became a volunteer for the Marketing team on 2/29/2012.

Click to see previous VoQs winners.

Are you between jobs and looking for something constructive to do? What if what you do between jobs could be converted into job experience?
 That is the idea behind PIT (Project Manager in Transition), a new program being offered by PMINJ.  Volunteer your time to become a working PMINJ project manager during your downtime, and continue to sharpen your skills or gain new ones. In addition, you will be able to gain valuable access to possible hiring resources, learn new roles, earn PDU’s and give back to your chapter.

 Close the gap on your resume by becoming part of PIT. For more information about the program and how to register.

 More details to come in the January 2014 newsletter!

Karl Pisarcyk / Project Manager, Corporate Outreach PMINJ and Dennis McCarthy / Director, Corporate Outreach PMINJ visited two of our satellite locations for the October 15 Program Meeting.

 "We are reaching out to our satellite partner companies and volunteers by sending Corporate Outreach Team members to various satellite locations for each of the monthly program meetings," said McCarthy. "The volunteers who work to staff these satellite locations and the companies who provide the facilities provide an invaluable benefit to the members of PMINJ and we want them to know that we appreciate it and would like to see if there is anything that Corporate Outreach could do for them."

 The operation of satellite locations for members to attend PMINJ monthly programs at no cost (and normally close to work or home) is a critical element in PMINJ's strategic objectives "to engage and develop members...", "to increase the value of PMINJ membership", and "to provide an environment that promotes participation and collaboration among members."

 Karl attended the September Program at the PSE&G location is South Plainfield, and Dennis visited the Verizon Wireless location in Basking Ridge.

 The Verizon site was very well attended and the two hosts, John Spaventa and Mike Otero (Louis Spadafora could not make the meeting), were very helpful and interested in hearing what the Corporate Outreach Team provides (in terms of speakers, lunch and learns, etc.).

 The PSE&G site was also well attended and the two hosts, Bill Herriott and Chuck Tkachuk, were very accommodating and appreciative.

 If your organization is interested in having a speaker for a specific Project Management topic, and/or conducting a lunch and learn session, please contact Dennis McCarthy at .
 

 

When we think of Thanksgiving, we probably envision a big holiday meal with family and friends.  We eat too much, relax, watch football and anticipate leftovers the next day. Unfortunately, for many families, Thanksgiving is another day of hoping they will just have enough food to eat.

 Did you know that 1 in 5 children in New Jersey do not have enough food to eat?  That's almost 400,000 children living in our state.  Food pantries in our area feed several hundred families each day.  For most of us, that is hard to imagine.

 The Community Outreach team is helping to fight hunger by organizing a Thanksgiving food drive for local food pantries. In the month of November, we have partnered with the Market Street Mission in Morristown for IPM Day and are also asking all of our members to bring a variety of Thanksgiving meal items to the November 19 meeting. Items requested include boxed stuffing, boxed mashed potatoes, canned vegetables, packaged gravy, cake mixes and frosting.  The items collected will be distributed to local food pantries who will provide turkeys.  Cash donations are also welcome as a donation of $20 can feed a family of six. The team collected about 400 pounds of food that was distributed to several food pantries throughout the state for the 2013 Spring food drive.

 With your continued support, we can make a difference and provide a special Thanksgiving meal to the needy families in our communities and for needy families throughout the year.

September's chapter meeting included a comprehensive program with networking opportunities, methodology training, chapter news and events and a preliminary introduction of future opportunities for PMINJ members

Judy Balaban, Chapter President of PMINJ, started this month’s meeting by recognizing the new and existing board officers and advisors. Newly appointed board officers recognized were Barbara Fuller, Raji Sivaraman, Lisa Blake, Mark Barash, and Kim Hinton with newly appointed advisors Linda Glickman and Bill Ruggles.

Our key note speaker, Kevin Aguanno, BA, MAPM, PMP, Certified Agile Project Manager and Certified SCRUM Professional, a highly recognized teacher of Agile with 25 years of project management experience presented “Why all the fuss about Agile?.” The presentation focused on the appropriate application of management methods to more complex, high change, highly detailed and/or failing projects. Agile focuses on deliverables, communication, team bonding, customer collaboration and velocity over the more ingrained standards of comprehensive documentation, following plan, contract negotiation and earned value. The benefits in using Agile include reduced waste, higher productivity, higher morale, dramatically improved quality and most importantly a more satisfied stakeholder. Some examples of major corporations which are now using the Agile method are Yahoo, Google and Sirsi Dynix.  

Kevin also hosted a 1-Day Agile Boot Camp on September 18th, where participants were trained on the basics of Agile Project Management. The workshop covered topics ranging from the Agile philosophy to requirements and scope change management and ending with metrics and status reporting. The workshop was well-received overall as evidenced by some participant comments:

“Content was useful and general enough to apply to everyone, but in-depth enough to provide solid methodology.”
 
“Very informative and gave very useful examples to demonstrate new concepts.”
 
“This bootcamp was excellent, it helped me understand many aspects that I need on a daily basis.”
 
“Nice job. I'm a beginner with Agile. This provided me with the knowledge I need to take back to work. My company is just starting to use Agile.”
 
“Great workshop. I was very familiar with the materials as I've been assigned to Agile projects for almost three years, but seminar still very helpful!”

Click to see pictures from September.

Our presenter for the October monthly program about the Adaptive Lean Six Sigma for project management was John Muka. John's presentation covered the key concepts of this methodology including time-based improvement, project streamlining to define the key elements which are most important to the client, and the prevention of process defects which can cause significant delays in productivity thereby decreasing the value of the work overall. The implementation of accountability processes for management also plays a key role in maintaining the productivity and efficiency levels to create a circle of accountability which eliminates the ineffective practices formerly addressed at the beginning of the project.

 John Muka possesses a Ph. D in PsychoEducational Processes, Team Dynamics and Adult Learning methods and also holds a certified Master Black Belt in Adaptive Lean Six Sigma. Following a prestigious career working for such well-known companies as General Motors and Robert Wood Johnson University Hospital, John formed his own company, AptoLean, Adaptive Lean Six Sigma, in 2010.

If you have an agile project larger than two or three feature teams, you have an agile program. A program is a collection of projects where the objective is one business deliverable. If you’ve managed programs before, you know how difficult it is to keep programs on track. With bigness comes more risk.

 One of the best ways to make sure your agile program is successful is to think about how to make everything smaller. Not in what the program delivers, although you’ll have the opportunity to deliver early if you follow these tips. But if you think about smaller for organizing the program, you might be able to manage the risk better.

 Here are six tips for making your large efforts “smaller” to achieve maximum benefit from your agile programs and to help them maintain progress.

Tip 1: Keep Your Iterations Short

Remember, the length of the iteration is the length of work you can afford to throw away. That’s the amount of time you have between feedback from the customer or product owner to the team.

 Now, the more people you have on the program, the more inertia the program has. Imagine you have a program of 100 people. If you have a three-week iteration and you have problems with that iteration, you might have to throw that iteration’s work away. That’s better than throwing a release of work away. But, do you want a three-week iteration, where you have 100 people times three weeks of work you might have to throw away?

 The more people you have on the program, the shorter you want the iteration to be. Maybe you can only afford a one-week iteration. Consider how long you want the iterations.

 And for those of you who are saying, “We don’t know how to make our stories that small!” that’s a program impediment and a risk. You need to learn that, and pronto. Because if you maintain long iterations, Murphy will come sit on your project, and you will have a long iteration you will have to throw away. You know you will. Keep your iterations short.

Tip 2: Keep Planning Short

If you have short iterations, you don’t need a lot of planning time for each iteration. You do need enough planning time for each iteration.  Each team needs to know how many features they can take for their iteration, and they need to know if they have dependencies with other teams.
 
 This is where small features helps with planning. If you have small features, you don’t have to spend any time estimating how long the features take. This is one of the reasons I like features that are so small you don’t have have to estimate the size of. The team can say, “Oh, we can do that in a team-day.” The teams just take in the features they know they can take into a sprint.

 But this does mean you’ll need to have a feature roadmap for the product and maintain the feature roadmap during the entire program.

 A feature roadmap is a living document. I’d expect the roadmap to change based on which features finish and which features you no longer want in the release. You know more about features early in the roadmap and less about features later in the roadmap.

 Since you’re thinking of short iterations, the early features are smaller and well-formed. The later features are larger and more vague. It is the Program Product Owner or the customer’s job to continue to work on breaking down the later features into smaller features for easy consumption later.
 Each team needs to know how many features they can take for their iteration, and they need to know if they have dependencies with other teams.

Tip 3: Make Architecture a Just-in-Time Activity

Ideally, you’d want architecture to occur as it’s needed, to evolve the architecture by refactoring as you would on a regular agile project. But on a very large program, especially, once you have more than nine feature teams, you might want more planning than just when you see a need for architecture, because you don’t have to have many feature teams waiting for architects to do their thing.

 Architects can look at the roadmap and do some prototyping in advance. They can do some wayfinding or exploration. The architects or feature teams should resist the temptation to do any big design up front. They should always let the features guide their exploration and refactor to patterns.

 Okay, I’m saying always here, which probably means that there is at least one exception to this guideline. But think hard and long about whether your program is an exception to this tip. The longer the architects or anyone works in front of when the actual feature is requested on the roadmap, the less likely the exploration is the right exploration. The less likely that exploration is in touch with the current code base, and more likely the exploration is waste.

 You want the feature teams to incrementally refine the architecture. That means the architects have to be embedded onto the feature teams. If they are not, that is a huge risk to the program. One of the deliverables I have requested for every iteration in an agile program is an updated picture of the architecture to see how the architecture evolves, bit by bit. You might request that, too, as a way of managing risk.

Tip 4: Integrate Continuously Across the Program

Continuous integration within feature teams is necessary in an agile project. That requires small stories to be integrated every day or so. What is not always given is continuous integration across a program. The larger the program, the harder this is. And, the larger the program, the more necessary it is.

 Again, the more feature teams you have, the more inertia you have. If you don’t start integrating from the start of your program, you will incur technical debt. So the best way to avoid technical debt is to integrate.

 Are there some programs where you cannot continuously integrate? Maybe. I have not yet met one.

 Start by using continuous integration inside each team. Make sure that teams understand that “done” means they can build and demo the entire product, not just locally, but for the entire program. Then make sure that each team integrates across the program so that the entire system is built as often as necessary and is green at the end of each iteration and demo-able at the end of each iteration.

 The larger the program, the more your program might need help, especially if this is a legacy product. Your first set of features for the program might have to be a re-architecture of the build system so that the feature teams can build independently and continuously integrate—if not independently, with minimum assistance from an integration team.

Tip 5: Encourage the teams to Communicate Like a Network, Not a Hierarchy

With feature and iteration smallness comes a need to communicate often. People can’t wait for a standup on other feature teams to talk to each other—they need to know right now what is going on with features, with integrations, with architecture, with testing issues. And, you don’t want feature team issues to have to be escalated to you. You want people to solve problems themselves.  Please reference the link which illustrates this.

You might have many kinds of feature teams. Some, like Sally’s, have several teams working in that one project. Sally’s project is a program itself. Joe, Tim, and Henry have just one team working on their set of features. All of these feature teams are cross-functional and have everyone they need to deliver their features. And, because they all know who each other is, they can communicate with each other when they need to. Don’t force a hierarchy on the feature teams.

 Think Small to Go Large

The larger you need the program to be, the smaller you need to think. It sounds funny, but it’s true. You have an epic feature? Break it down into small features. You want to accomplish more? Try shorter iterations. You want to make sure you have the product ready for release? Use continuous integration at the beginning of the program, everywhere in all feature teams. You want to make sure you have an architecture that works? Integrate architecture into every team’s work. Want to make sure the teams know what’s going on? Think network communication, not hierarchy.

Try these five tips and see how your agile program proceeds. I bet you too will find that going smaller will allow you to scale your agile program larger.

 Johanna Rothman is the author of “Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects” and the Jolt Productivity award-winning “Manage It! Your Guide to Modern, Pragmatic Project Management.” Her upcoming book about agile program management is “Agile And Lean Program Management: Collaborating Across the Organization,” on leanpub.com. You can read more of her writing and blogs at her website .