• Link Planbox items and GitHub issues
• Easily follow development progress from Planbox
• Access Planbox information from GitHub

You can check out the documentation, and download our Chrome plugin.

Here is a preview of the feature:

If you’re looking to integrate Github functionality with an agile project management tool, you’ll be happy to read that we’ve been keeping busy revamping our original Github integration (stay tuned for a launch date in the coming days).

If you are an extension developer, and you have read Github’s recent blog post on its implementation of a Content Security Policy, you may feel screwed.

Here is how we bypassed Github’s Content Security Policy with our Chrome extension:

Just modify the initial page request, and everything will be fine.

Here is our manifest:

Don’t forget the “webRequest” and “webRequestBlocking”  permissions in the manifest It enables you to intercept the HTTP response header before the page actually gets its. Here is the background.js source

It’s just adding “https://mysite.com” to the list of authorized hosts for stylesheets and scripts.

Enjoy

Functionalities in Planbox

• Creating an item from a Zendesk ticket
• Syncing file attachments in an item linked to a Zendesk ticket
• Searching for items linked to a Zendesk ticket
• Update Zendesk ticket statuses

Functionalities in Zendesk

• Creating a Planbox item from a Zendesk ticket
• Assign the item to different iterations in Planbox
• Access a Planbox item from the Zendesk ticket its linked to

The Old Planbox Widget in Zendesk

The old Planbox integration (known as the Planbox Widget)  will continue to work in the Classic version of Zendesk, until Zendesk stops supporting its classic version. However, on the Planbox side, we’ve stopped updating the old widget, since we’ve launched the new Planbox App in the new Zendesk.

Once you switch to the new Zendesk, all your tickets previously linked with Planbox items will continue to function normally. no worries! So why wait? Switch to the new Zendesk now to starting using the integration with all the new functionalities.

Getting Started for new Zendesk users

If you are new to Zendesk, you will first need to create a Zendesk account for your organization. Once logged into your Zendesk account, you can install the Planbox app from the Zendesk Apps Marketplace  located in the Manage Cog.

From your Planbox account, you will need to go to your initiative’s Manage Page. Under the Features section, make sure that you have the Zendesk integration enabled.

For detailed instructions, please consult the Zendesk Integration Support section.

Zendesk had already received a lot of love for their classic version, but last year, they made their application even more awesome by redesigning its interface. According to them, here’s why you should love the new Zendesk even more. It has:

1. Improved agents interface
2. Better access to support data and metrics
3. Redesigned business integrations

If you are still using the classic version of Zendesk, you should seriously consider switching to their new version to benefit from the improved functionalities. If you are not convinced, read their FAQ here.

Zendesk’s App Marketplace

The redesigned Zendesk business integrations platform is where Planbox comes in. Whether you mainly work in Planbox or in Zendesk, with the integration, you can now manage your customers and your projects together.

If you used the old Planbox widget in the classic Zendesk, once you switch to the new interface, be sure to check out the new Planbox integration with Zendesk for even more functionalities. It is now available in the Zendesk app marketplace.

If you’re new to all this, simply activate the Zendesk integration with Planbox to start creating Planbox items from Zendesk tickets.

>> Take the survey now <<
Survey duration: 9 minutes approx.

Each year Actuation Consulting and Enterprise Agility undertake a global study of product team performance. This is the second year of the study and the amount of industry interest and participation continues to increase. This year the amount of professional associations, vendors, and promotional partners supporting the survey had doubled. The study is designed to closely examine the factors that improve or impede product team performance.

This study will assess the dynamics of product team performance and determine what factors impede or improve product development outcomes. For the purposes of this study, the core product team consists of product managers, project and program managers, user experience professionals, business analysts, development managers, and engineers.

This year’s sponsors include:

- The Association of International Product Management and Marketing (AIPMM)

- The International Institute of Business Analysis’s Chicagoland Chapter (IIBA)

- The International Project Management Association (IPMA)

- The Product Development and Management Association’s Chicagoland Chapter (PDMA)

- And Planbox

In addition to the sponsors, the study enjoys a unique and wide variety of promotional partners. These include: the Chicago Product Management Association and Product Camp, Global Product Management Talk, Lee Lambert of the Lambert Consulting Group, Orange County Product Managers, the Project Management Institute’s Chicago Chapter, the ProjectTimes, Product Management Talk, the Silicon Valley Product Management Association (SVPMA), the Software and Information Industry Association (SIIA), and the User Experience Professionals Association (UXPA).

As you can see the study’s ever expanding list of partners encompass product management, project and program management, user experience, business analysts, development managers, and engineers at all levels.

So, as the study enters its second year it now has all the core roles covered and we anticipate increasing last year’s level of participation significantly. Please take a moment and share your thoughts with us. We want to hear from you and learn more about the effectiveness of your product team!

You can take the survey today by clicking here. The survey is open from January 15th – February 28th or until there are 3,000 responses. Whichever comes first.

The study findings will be made widely available through the sponsors and promotional partners and at Actuation Consulting’s website.

Meanwhile, you may also learn about some of last year’s findings by viewing this webinar, presented by Actuation Consulting’s Greg Geracie and Steven.

We’ve happily outgrown our old office that we shared with a startup in Montreal! As the new year begins, our team has moved into a new and bigger office. It’s great to have our own space now, and we’re another step closer to getting our dream office . Moving offices sometimes feels like moving apartments. We do spend more than 40+ hours at work after all. Even though construction hasn’t been completed yet (we’re missing lights!), we’ve already settled in quite comfortably.

This is where we do all our work. Before, we used to have our desks lined one next to the other. Now, we’re grouped per function to face each other so that we won’t have to shout across 5 people anymore.

Our cozy kitchen area is almost perfect, but we’re missing 2 vital components: coffee machine and beer keg!

Fun fact: our conference room is called the Barn.

Finally, our lounge area. A dream soon to come true: we’ll be playing video games together on a projector here during lunch and after hours. Soon. Very soon!

Bonus:
We had our holiday season party in the new office. Check out our bunch of good lookin’ folks.

A bit more about Neuralitic

Find out how Planbox helped Neuralitic
Read the Case Study

We always prefer to speak directly when possible,  so instead of doing a profile interview in text, we decided it would be fun to make a video. Here’s a first!

Organizational Agile Transformation – Big Bang Approach?

In my last post in the series, I thought I would have a little fun. I was recently talking with a peer about the challenges organizations face when rolling out Agile. He mentioned that he was talking to a client later in the day and wanted to know what my recommendation was. I said “in my experience, you have to take an agile approach to actually rolling out Agile to an organization.  Agile brings about change, and depending on the culture of the organization, it may take time to fully adopt. An incremental approach is the best way to roll it out.”

He asked, “what if the client wants to rip the band-aid off and roll it out all at once?”  I responded half-jokingly… “well it depends on how many bodies they want to leave behind in the process.”  However, the more I thought about his question, the more I wanted to challenge my initial answer.  Rolling out Agile in a big bang approach really seems counter-intuitive considering what we are rolling out. However, rolling Agile out iteratively brings up the concern on how well Agile can scale.  An Agile roll-out out to an enterprise can involve several hundred people made up of a multitude of cross functional teams. Should we expect Agile to scale to this level?

From my industry experience, I’m finding more and more CIO/CTO types wanting to take this big bang approach. They want to make the leap and they want to make it now! However, the approach we take for roll out can make or break its success.  Is the best approach in rolling out Agile to an organization done through actually running the roll-out like an Agile project or is a big bang approach better?

I’ve attempted to break down some of the key components of Agile to try and answer this question.

1.  Communication

Increased and valuable communication is a key Agile principle. Agile works great within enclosed teams of 10-20 people. Because of the smaller team size, most team members actually (dare I say) develop friendships.  Agile doesn’t necessarily work when thousands have to interact. It’s extremely difficult to get somebody from another geographical location, participating in a project, trying to be friendly, and trying to get information at request.  Agile just doesn’t seem to be designed to scale.

2.  Lack of documentation

Because of the increased communication and conversation, the need to document in an Agile project isn’t really required. Agile is very light weight and is about just enough documentation. However, at the enterprise level, rolling out a new methodology (Agile) requires communication to be crisp, coordinated, and concise. Because of the different perspectives, constraints, and cross-functional priorities, a roll-out needs to be managed very tightly. A roll-out of this size requires that things get documented. Again, I would have to say that running an enterprise Agile roll-out through Agile principles doesn’t seem to be the right way to go.

3.  Self- Organizing Teams

The concept of self-managing teams organizing around goals given constraints works excellent on smaller Agile teams of 10-15 people works. However, an army of people cross-functionally based and geographically dispersed, just simply needs some order in order to function healthy. At the enterprise level, lack of formalism doesn’t lower chaos, it actually ensures chaos.

All in all, I still came away thinking that my initial answer was correct. Either path likely faces the above challenges. It’s a question of what makes more sense for your organization and is likely to gain more support among leadership: rip off the band-aid, have short-term pain in the hopes of long-term gain; or pilot your way into it so as to manage the risk of disruption, but risk losing support if tangible progress can’t be demonstrated and other agendas begin competing for resources.

An enterprise roll-out of Agile, does require some up-front planning and clear communication and structure. Yes, a more pragmatic, iterative (RUP like) approach would probably seem to be the best way to go. I know I may receive hate mail on this one, but dare I say, I recommend running an enterprise Agile rollout through your neighborhood PMO. I’m actually blogging about the PMO’s involvement during an Agile transformation at http://www.actuationconsultingllc.com/blog/

Regardless of which path you take, be sure to go in with eyes wide open!

This is the last in a series of three guest posts on this topic from Steven Starke, author of S.T.O.P The Project Management Survival Plan and partner at Actuation Consulting. Steven Starke is the author of S.T.O.P. – The Project Management Survival Plan. He is currently the VP of Program Management for Truven Health Analytics (formerly Thomson Reuters Health) and working with Actuation Consulting on training material focused on product team collaboration. Steve has held leadership positions in Program Management, Product Management, Systems Engineering, Product R&D, and Global IT and has run full-fledged PMOs. His industry experience ranges from consumer products and medical devices to global IT Infrastructure, healthcare analytics, and software development. Steven can be reached at Steve@actuationconsulting.com and networked with via his LinkedIn profile. Read more about Steven.

Last week, we hosted an agile adoption case study webinar. We invited Si Alhir and the AutoVIN team to speak about their experience as their company ventured into an agility transformation. The team members  share their perspectives from their different roles in the journey, and offer specific actionable lessons they’ve learned that you can leverage in your own agile transformation.

Watch the full webinar recording here. 

There was so much great content in the discussion that we didn’t manage to have a longer Question & Answers period. Si Alhir and his team took the time after the webinar to answer some additional questions. If you have more, please post them in the comments section!

Questions & Answers

Q. What was the initial planned timeline for the (AutoVIN’s) Platform project?

A. As the AutoVIN solution/platform is continuously evolving, there was not an “initial planned timeline” per se, but the objective of maximizing the efficiency and effectiveness of the team, capitalizing (between ADESA and AutoVIN) on the vehicle inspection and reporting platform, and integrating a more-agile team with other less-agile teams (and world).

Despite that there were no initial planned timeline, circumstances forced a timeline and change in scope. Being agile has allowed this to happen more easily because features were prioritized from highest to lowest according to usage and broken into smaller amounts of work.

Q. Was User Experience design part of this process? or only back-end work?

A. Usability / User Experiences is a facet of the Product Owner role and Define-Detail perspective (of the Define-Detail, Build, and Test aspects of the Team) was continuously considered. User experience was part of the process and was essential in the adoption of the rollout plan for the new platform. Technology should make it easier for the user.

Q. Can agile methodologies be used in bigger teams? Is there a team size limit? For example, in a company of about 250 employees?

A. Agile adds flexibility and improves communication through usable software. The flexibility comes from the smaller increments of work that allow the features to by more easily aligned with the schedules of other teams.

Agile and Agility readily apply to larger and smaller teams. Scaling is not problematic when approached and designed deliberately. See the car.com case study for more information.

Q. How can the use of virtual project management tools or issue tracking tools help in an agile transformation journey? (other than helping teams working remotely). Especially for different teams that are used to work on its own domain and has it’s own planning board of activities?

A. The virtual project planning tool should be able to make changing plans an easier task. Priority can change due to the many influences on a product/project and with any transformation journey there is a discovery process that should not be hindered by tools.

Tools are valuable when they advance (versus impede) healthy human dynamics (well-being) and don’t introduce or perpetuate unhealthy human dynamics in support of overall performance. The crucial question about tools is “why” (benefits and detriments), the other four Ws (who, what, when, where), and “how”.

Q. I understand you don’t want to stifle creativity in the software development process, but at where do you draw the line, so you avoid doing R&D while on a project? I’ve tried to keep R&D outside of the project.

A. R&D happens throughout the project. Some may be up front to get comfortable with the scope but an important part of the process is to allow yourself time to plan ahead. As with anything creative, it requires outside inputs or situations and the best way to find these can be through implementing and experiencing the results of the product. The best validation of a need is through use, just keep the features light to limit the risk.

The crucial question concerning Agility is “what is value” (and how is it discovered and delivered). Once “value” is recognized, all things are balanced against it, for example, how much capacity we have, how much value is needed now versus later, and how much can we offered to focus on R&D now versus later, etc. Technology research & product development and market research & product design are partners in the overall discovery and delivery cycles around value. The Value questions is paramount!

Q. If you could offer one key recommendation to others interested in becoming more agile or achieving greater agility, what would that be?

A. AutoVin team: “Go all in, don’t give up early or alter the process at first. It can be difficult to improve and enforce positive habits/behavior.”

Si: One key recommendation is focus on Agility (not merely Agile Development), and don’t get “caught up” in dogma!

Q. What was the most “surprising” thing about your journey?

A. The most surprising part was how much the process aided in the team dynamics and improved morale.

Q. If you could do one thing differently what would that be?

A. Starting the journey earlier. It may have changed the decision around the office closing.

Q. What was “easier” than expected? What was more difficult than expected?

A. Easier: Starting our first sprint/iteration after iteration 0 (Getting to work without a thorough plan and trusting ourselves).

Difficult: Working with a less agile enterprise. Everything seems like an emergency and outside processes seem slow. It requires more planning to account for the different paces (heartbeats) of a less agile organization.

Click here for the slides of the webinar.

Si Alhir is a Practitioner and Consultant/Coach (Transformation, Change Management, and Organizational Development).He has over three decades of proven experience in transforming organizations/enterprises by synergizing Business and Technology around proven industry-recognized & organization-tailored principle-based practices and by cultivating effective Communities (of Interest, Practice, Engagement, and Purpose) that sustainably deliver impactful results. He leverages a broad and deep background in all aspects of technology product/services management (planning, marketing, and sales) and engineering (development), including business development, client management, and consulting services. Read more about Si.

Many teams and organizations enact Agile practices yet don’t realize the benefits — to accelerate time-to-market, manage changing priorities, increase productivity, enhance quality, further align Business and Technology, improve visibility, reduce risk, and reduce cost — and are then forced to confront embracing an Agility mindset while many other teams and organizations embrace an Agility mindset yet don’t realize the benefits and are then similarly forced to confront enacting Agile practices. This dichotomy between practices and mindset is a “chicken or egg” problem, and strictly enacting the “letter” or embracing the “spirit” is problematic. Merely embracing a mindset often delays demonstrable benefits and merely enacting practices doesn’t achieve sustainable benefits, yet authentic success involves integrating (not merely balancing or compromising) the “spirit” as well as the “letter” in adopting, scaling, and sustaining an Agility mindset and Agile practices, both within teams and across organizations where “the whole is other than the sum of the parts”, which fundamentally involves Transformation.

On November 28th, 2012, AutoVIN, The Automated Vehicle Information Network, a subsidiary of ADESA, will share how it achieved greater Agility by integrating the Spirit of Agility and the Letter of Agile! We’ll explore how management and the team aligned around the nuances of the business problem and the complexity of the technology solution to discover and deliver Value, and how the transformation journey interweaves business, technology, and culture.