Using Zendesk to Manage your Customer Service

Tuesday, February 5th, 2013

Making sure that your customers get the best of your attention will help you create a delightful experience for them with your company. Zendesk is a online help desk application that will help you manage all that by shortening your response time, automating your workflows and providing you with reports.

 

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.

line

Join the Study of Product Team Performance and Let Your Voice Be Heard!

Thursday, January 17th, 2013


The survey is open from January 15th through February 28th.

Take the survey now: Product Team Performance

>> 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.

line

Let’s End the Debate! Scrum Master versus Project Manager – Part 3 of 3

Monday, December 3rd, 2012

Missed the other parts? Read them here: Part 1 or Part 2

 

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 StarkeSteven 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.
line

Let’s End the Debate! Scrum Master versus Project Manager – Part 1 of 3

Monday, October 22nd, 2012

Over the past several years, there has been much debate and confusion over the role of a project manager as the majority of organizations undergo some degree of Agile transformation. In fact, industry data suggests that approximately 53% of organizations are blending Agile methods with Waterfall.[1]

I can’t tell you how many articles I’ve read, and LinkedIn postings I’ve seen, on these subjects. The best material recognizes that a project manager is NOT a Scrum Master and vice versa. And although the description of the Scrum Master role is usually pretty clear in these discussions, nobody has done a really good job of explaining how the two roles (Scrum Master and Project Manager) co-exist or how this role confusion started in the first place.

To be honest, I really never understood the debate until recently as my organization decided to embrace an enterprise agile transformation (which I’ve been blogging about at http://www.actuationconsulting.com/blog/).

I started executing projects back in 2001 using XP (Extreme Programming) and I never had any issues with team members regarding role confusion during project execution. Agile wasn’t evil – Agile worked. Well, fast forward to 2012 and the debate continues to rage on. I finally got sick of watching the continuous debate and decided to take action. I took the classes, passed the test, and became a Certified Scrum Master. And after that investment of time and money, I can honestly say with certainty, I’m not a scrum master – I AM a project manager!

Fundamentally, I think the root cause of the debate is not based on scrum master versus project manager responsibilities but based on our fundamental definition of a project. In the Agile world of minimum marketable features (MMF’s), product backlogs, and continuous integration, the lines of the traditional project have now been blurred.

Let me get some quick definitions on the table to help structure our conversation:

The Scrum MasterThe Scrum Master focuses on the development process and mentors the Scrum team. The key responsibilities of the scrum master are:

  • Maintaining and removing impediments
  • Managing the Scrum process, making the process work
  • Planning the release
  • Planning the Sprints
  • Shielding the team from external interfaces
  • Facilitating Scrum meetings as requested
  • Ensuring crystal clear communication among everyone involved in the project

A Scrum Master is usually the team leader. A Scrum Master should ideally have a good balance of the following skills:

  • Technical expertise
  • Understands the Product Owner’s intent
  • A good team player and mentor
  • Understands the teams capabilities
  • A good motivator
  • Problem solver

Now let’s take a closer look at the program and project management roles and responsibilities by defining a project and a program…

Project: A temporary endeavor undertaken to create a unique product, service, or result. At most organizations, the boundaries of our “temporary endeavors” are defined through our business cases.

Program: A series of related projects designed to achieve a specific outcome(s).

To state it concisely, the role of the project manager is to manage all (ideation to post-launch support) aspects of the project to achieve the expected outcomes identified within the established business case (investment) – not just the Scrum team. The size, scope, and complexity of the business case will determine the size of the project. Achieving outcomes called out in the investment may take a series of related projects – called a program. At which point, the program manager is now accountable for managing all aspects of the program, with project managers and other accountable resources managing their smaller project portions.

Right now, there are three, possibly four basic categories of “temporary”:

    1. Product line execution – Temporary relative to a 1 year planning cycle. Basically covering minor incremental enhancements to an already existing product line.
    2. Big custom projects / new product development
    3. Within the product line – Specific temporary initiative/projects. For example, a SQL server upgrade.
    4. Cross organization initiatives – Examples that come to mind are rebranding, ICD-10 (healthcare), data center migrations, etc.

These projects / temporary endeavors at most organizations typically look like this:

Program Management View
And it looks like this…

Alternate View

If this is a project, then the project manager needs to be the one accountable person responsible for managing all of this work (or for understanding and managing HOW we’re going to get the answers to the questions above in each circle) – They are not responsible for answering the questions!

To put it simply – the project manager is responsible for managing all the boxes together to achieve the desired outcome. They may or may not be responsible for managing the individual boxes. Individual box responsibility is typically done by the subject matter experts.

As you can see, Agile development and the Scrum team are only one box!

Specifically, the project manager is responsible for:

  • Understanding the intended outcomes of the project and ensuring the outcomes are realistic and measurable. They need to understand the outcomes expected from the business case!
  • Collaborating with the team to define the scope of work (e.g. under each colored box above, what’s in it, what is the expected outcome), who is responsible for delivering it, and when will it be delivered. Specifically:
  • Understanding the point person from each functional team(s) associated to the work (each colored box) and how they have been allocated for managing their work. If allocation bandwidth issues exist, this person would be responsible for facilitation and ultimate resolution of the resourcing issue.
  • The job of the project manager is to remove ambiguity in roles and responsibilities by clearly mapping out activities against expected outcomes relative to time. Identifying the interdependencies between deliverables and functional teams up front will better determine what teams should be more integrated and when, relative to the overall product development process.
    • Deliverables required to complete all the project work
    • Cross-functional resource assignments
    • Estimates to complete the work and dependencies between work items

Important note: if the scope of work is large enough, another project manager/person may be assigned to specific items (smaller box). The relationship would be a dotted line from this other person to the project manager.

Said another way, if each one of the smaller boxes above is large enough in scope to be considered its own project, then the program would consist of several related smaller projects rolled up underneath the program.

    • E.g. Hardware or software procurement, installation, and configuration – Application Operation Project Manager
    • E.g. Agile product development – Product owner/scrum master
  • Understanding the process and tools required to manage the scope of work relative to the outcomes identified in the business case. Understanding the metrics and the process for achieving those metrics/goals.
    • If an identified metric is that the project be completed within a certain capital budget, then the project manager is responsible for understanding the tools and processes required to forecast and track the work. They are NOT responsible for creating or establishing those processes – unless of course that creation has been identified as another project!
  • Project managers are responsible for the overall communication regarding the project (not just the development portion of the product). They’re the primary single authoritative source of information to ensure a shared understanding of all parameters:
    • Scope
    • Cost management
    • Timing
    • Assumptions / constraints
    • Risks / issues
    • Resources
    • Quality
    • Special considerations / exceptions
    • Development methodology considerations
    • Team members and associated roles and responsibilities
    • Policies and procedures

So, if you agree with all of the above, is there really a debate between the two roles?


[1] The Study of Product Team Performance, 2012, Actuation Consulting LLC and Enterprise Agility Inc.

 

Read Let’s End the Debate! Scrum Master versus Project Manager – Part 2 of 3

 

This is the second 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 StarkeSteven 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.
line

Agile Adoption Webinar (Part 2): Infographic

Wednesday, October 17th, 2012

Last week, Planbox invited Greg Geracie and Steven Starke from Actuation Consulting for a live webinar about agile adoption. The webinar was based on their recently published study, in which they uncover 5 common key factors that were all present in high-performing product teams. In addition, they authors discuss recent trends in project management methodologies.

 

Watch the full webinar recording here. 

 

In this second part of a series of 2 blog posts about the agile adoption webinar, we present you a quick summary of the important data that was shared during the presentation.  If you like it, remember to please share it!

 

Agile Adoption Infographic by Planbox

 

You might also be interested in:

Agile Adoption Webinar (Part 1): Questions & Answers

line

Agile Adoption Webinar (Part 1): Questions & Answers

Wednesday, October 17th, 2012

Last week, Planbox invited Greg Geracie and Steven Starke from Actuation Consulting for a live webinar about agile adoption. The webinar was based on their recently published study, in which they uncover 5 common key factors that were all present in high-performing product teams. In addition, they authors discuss recent trends in project management methodologies.

 

Watch the full webinar recording here. 

 

In this first part of a series of 2 blog posts about the agile adoption webinar, we will share with you some questions that attendees had for our guest speakers. Thank you to Greg and Steven for having provided some very insightful answers.

 

Questions & Answers

 

Q. Limited resources seems to play a major role in our company going full Agile. We don’t have a business analyst (BA), our Product Manager is part-time, and our development teams span across products. Is this a common roadblock or are we just not disciplined?

 A. (Greg) - In my experience, fully implementing Agile is more resource intensive – not less. The Agile process is particularly demanding of a product

manager’s time. Executive teams often don’t fully understand the resource intensive nature of Agile implementation and underestimate the need for additional resources. This frequently means that market-facing and more strategic activities suffer as the team devotes its energy to covering pressing tactical activities. This is costly in the long run. Under-staffing is not uncommon, particularly now, as organizations have aggressively downsized due to the current economic situation. However, to be most effective the team needs to be properly staffed.

 

Q.Did you find a correlation between a particular type of methodology and a higher rate project success?

A. (Greg) - The short answer is no, but we intend to take a closer look at this in next years study.

 

Q. Is the high prevalence of waterfall because waterfall works (in some cases) or because Lean/Agile is hard to embed in the larger cultures?

A. (Greg) - I think there is truth to both of your comments. From my perspective, no single product development methodology is a panacea for all the types of product development challenges. So waterfall continues to be robustly used, even if the current conventional wisdom is that it’s “old school” and part of the past, because it’s effective when used under the right conditions, particularly within large and complex organizations with large and complex projects. Waterfall continues to have a tight hold on manufacturing type environments where predictability is highly valued.

(Steve) – The waterfall approach is much easier to govern for Senior Managers and Executives as opposed to an Agile approach. Especially, in a world where outside bodies are required to regulate the work, a waterfall approach is easier to explain and very deliberate in terms of deliverables. It may take “longer” but it may pass an audit much quicker. That reason alone is why some organizations are very pro-waterfall and why it’s still very prevalent throughout the industry.

 

Q. Diana Larsen’s new book – Liftoff has a very specific process for chartering Agile teams and projects. It’s a great way to communicate strategic and tactical vision. Would something like that inform the team with enough information to enable them to help “on board” new members?

A. (Steve) – I have not read Diana’s book so I can’t speak to specifics on it’s effectiveness. However, generally speaking, any tool or approach that increases communication around both strategic vision and and tactical execution would definitely help in providing the additional context required to effectively on board new team members.

 

Q.What does the data show about which methodology is dominant in different phases of a project?

A. (Greg) - Excellent question! The data does not break the responses down into the different project phases but looks at the prevalence of the dominant process overall. However, you raise an interesting point given the findings.

 

Q. I’ve seen some organizations describe the workflow such that the process of deciding what goes into a product is waterfall, but how it gets built is “Agile” (iterative incremental). Can your findings expose situations such as these?

A. (Greg) – Since this was the first time we ran the study (we’ll continue to conduct it annually) we did not structure the questions to capture the situations you’re referencing. However, as noted earlier, given that we have established a baseline we can now dive into the findings with more rigor, which we intend to do in upcoming surveys.

 

Q. What do you think of “valve software-like” approaches with flat hierarchies and self-organizing teams?

A. (Greg) - I’m well known for being product development methodology agnostic. I believe that you have to select the best approach based upon what you’re trying to achieve, the skills available to you and the team, the level of available resources, etc. However, whenever you can have a streamlined and self-motivated team with an internally driven sense of purpose and high levels of commitment you’re more likely to succeed (in my experience).

 (Steve) - I completely agree with Greg. Self-organizing teams, acting in the true spirit of getting the work done, despite role and organizational structure constraints, are extremely successful and valuable to an organization.The only word of caution is to ensure that “self-organizing” doesn’t mean ”self-governing”. A certain amount of organizational governance is still required to ensure the team is heading in the right direction based on organizational goals and objectives.

 

Q. Why is there a positive correlation between increase in waterfall and size of company?

A. (Greg) - Several factors likely contribute to this. First, large organizations typically have large and complex product development projects and waterfall is normally chosen to address these types of challenges. Second, large organizations need to train a significant amount of personnel to fully convert to Agile, so even if they decide to do so, it’ll take much longer and be more costly (assuming that they don’t decide to outsource development). Third, mature organizations that are successful in the marketplace have less reason to change what has worked for them. And even if they decide to change, it’ll take longer to turn the battleship around.

 

Q. Does “blended” mean that some teams are waterfall and some agile, or that some processes are waterfall and some processes agile?

A. (Greg) – Blended actually means – in terms of our survey results – that organizations are using an iterative incremental methodology (Agile) and combining it with waterfall in some fashion. The actual way this is being done at the “local” level varies based upon the organization. We’re aware of at least 5 different variations on this theme and we’re convinced there are even more that we have yet to encounter.

 

Q. Will you be sharing any details about the blended methodologies – how do companies blend the two methods, different by project, by project phase etc? Also, why is blending done?

A. (Greg) - We did not collect the actual ways this is being done in the survey data but have since gleaned some insight into what’s actually taking place from follow on conversations. You can expect to see more details about what we have learned in next years white paper.

 

Q. Regarding factor four [Assigning core product team members based on the skills needed] – given resources in companies are always tight, how do you suggest multiple projects are staffed and supported through launch?

A. (Steve) – I truly believe the size of the portfolio will dictate the level of enterprise resource management required to sustain product development through launch. As soon as assumptions are made with resource allocations, is as soon as projects are understaffed.Resources managers really need to understand what the true outcomes are of the project and ensure resources are staffed until those outcomes are achieved – through launch. A well functioning enterprise resource manager role can balance out the resource pool and look for opportunities between resources and projects as different products approach launch at different times. A role within a PMO can serve this need or someone specifically hired to do enterprise resource management.

 

You might also be interested in:

Agile Adoption Webinar (Part 2): Infographic

line

Agile Adoption – More to it than meets the Eye

Sunday, August 26th, 2012

The following guest post is written by Greg Geracie, President of Actuation Consulting. Actuation Consulting is a leading provider of training and consulting for product managers and product teams. This post is tied to another post that Greg has done entitled; Product Development Methodology Statistics

 

Agile Adoption in Relation to Other Product Development MethodologiesAgile methodologies have become a component of everyday conversation in the product development world. While widely adopted, confusion remains about what Agile really means and how to best utilize these methodologies. In fact, a recent study by the analyst group Voke indicates that half of the organizations that they surveyed did not have a consistent definition of what Agile actually means!

To be honest, this should not come as a surprise. While Agile has been around for quite some time organizations are still in the process of determining how to ideally utilize these powerful methodologies. While Agile has successfully planted itself into most organizations, there is more to this than meets the eye.

Actuation Consulting recently conducted a global survey of product team performance. The central result of the study was that we discovered five factors that, if effectively implemented, provide product teams a 67% chance of becoming high performing.

However, contained deeper within the study findings was another powerful set of facts related to the current use of different product development methodologies.

Survey respondents stated that approximately 13% of organizations were using “pure” Agile methodologies. “Pure” meaning that iterative incremental techniques were not being mixed with other methodologies. Surprisingly, 18% of organizations said they were “pure” Waterfall. More than you might have expected! Contrary to popular belief Waterfall is still alive and well.

At this point you might ask two questions. 1) How can Agile be so small a percentage? And 2) if Agile and Waterfall combined make up 31% – what method makes up the rest?

Good questions. Let’s take number two first.

The answer is “blended” methodologies. 53% of organizations state that they’re combining Agile and Waterfall together to address organizational challenges. They’re doing this in a variety of ways based upon the needs of the organization. Some are using Agile for new product development since it’s an effective way of hedging investment risk. Others are using Agile for “high value” product development projects. The variations are quite extensive.

So perhaps the best way to think about Agile’s reach is to combine the blended and “pure” Agile numbers together. Calculated this way 71% of organizations are using Agile to some degree – almost three-quarters.

As you might expect, pure Agile is skewed heavily toward earlier stage organizations. Pure Waterfall organizations tend to be larger in size and scale. However, the blended approach is consistent across all sizes!

There truly is more to Agile adoption than meets the eye!

Actuation Consulting and Planbox will be doing a webinar on this data and other relevant findings from the study, planned for the latter part of September. Stay tuned for dates and times.

line

Planbox wins Emerging Entrepreneurs Contest at C2-MTL 2012

Tuesday, May 8th, 2012

We are proud to have Olivier Cabanes of Planbox, and Martin-Luc Archambault of Wajam, represent the family of Bolidea startups at the C2-MTL conference. Planbox is honoured to have been selected as a winner among the 315 startups that have applied to the Emerging Entrepreneurs Contest of C2-MTL, back in February. Sponsored by the Claudine and Stephen Bronfman Foundation, the contest was launched to give the opportunity to 25 emerging entrepreneurs of Québec to attend the prestigious conference for free.

 

C2-MTL Logo

 

C2-MTL, a new international business conference integrating creativity and commerce, will be happening in the creative hotbed of Montreal, Canada from May 22 to 25, 2012. Business professionals from various industries will get to “explore creative answers to commercial questions” in The Village, a venue built especially for the occasion.

 

C2MTL c2-mtl village of innovation

The Village of Innovation

 

Sid Lee, with partners Fast Company, Cirque du Soleil and HSM, has created this unique experience for the participants of C2-MTL to learn from and to discuss with high-profile speakers. All-stars such as Google’s CFO Patrick Pichette and Walt Disney Group’s former CEO Michael Eisner will change the history of presentations forever with interactive exhibitions, state-of-the art projections, collaborative workshops and much more.

Here’s a little preview of what’s in store for the lucky attendees of C2-MTL:

 

Congratulations to all the other entrepreneurs who have won!

All image credits to: C2-MTL

line

Agile Project Management: Progress, Speed AND Direction?

Wednesday, July 20th, 2011

Planbox is glad to present this guest blog post by Crazie Eddie aka Pat Gray. Pat Gray is a writer, irreverent project manager, dog-lover, ex-wage slave and common sense champion cruising down the information super-highway. She Tweets as @Crazie_Eddie and @Pat_Gray.

“Progress has little to do with speed, but much to do with direction.”-Jorgen Larsen

I spotted this quote on Twitter and for some reason it got me thinking about Agile development and Agile project management.

Agile Project Management

When I originally heard about this new faster way of delivering projects, I was skeptical. I should probably confess at this point that I bill myself as the “Irreverent Project Manager”. I’m not impressed with project management methodologies in general. I’m definitely not impressed with companies and PMO’s falling under the spell of the latest fad methodology, whether it gets the job done faster or not.

I do, however, like the idea of getting projects over with quickly and not just because it makes the customers and upper management happy. Actually, like many people, I prefer the “enthusiasm” phase of projects to the “panic and hysteria” or “search for the guilty” phases, and the sooner you’re done, the sooner the next “enthusiasm”  phase begins.

Having said that, I think speed for the sake of speed in a project, especially speed without direction, is kind of like a taking a spin in speedboat without a steering wheel – the ride (your project’s progress) is going to be exciting, over quickly and probably end in disaster.

However, I looked into agile development and agile project management anyway and despite myself, I was kind of impressed for several reasons.

First, the agile development manifesto is a list of only twelve points which focus on delivery, team organization and customer satisfaction rather than a complicated methodology.

Second, the emphasis is on building a deliverable, not writing detailed specifications, or adhering to complicated design or change control procedures.

Third, I felt a bit more confidence in the people who put the manifesto together. There were no “thought leaders” who were “proactively leveraging synergistic best practices”.

Fourth, agile development relies on agile project management. I like the idea that project managers are leaders, that teams work with the customer rather than against them and that more emphasis is placed on value rather than cost.

Finally, the agile method isn’t like other more “evangelical” methodologies. Agile isn’t “my way or the highway” – project managers and teams can incorporate just a few agile principles in any methodology to improve their ability to deliver.

And my research made me realize, yet again, how few guarantees of project success we actually have using the “old ways”. Relying on a good team, focusing on customers and deliverables, and embracing change rather than spending all of our time fighting it is a much better way to go.

So maybe agile is THE methodology I’ve been searching for: progress, speed and direction. What project manager, irreverent or not, could ask for anything more?

line

Agile Transition: baby steps to a baby-smooth Agile transition

Friday, March 4th, 2011

Agile transition

A lot of our users at Planbox are either new to Agile or not Agile at all. For them and everyone who strives towards agility out there, we decided to write a strategy guide for a Smooth transition to Agile. Keep in mind that Agile works for just about anything.

An Agile tale tells us that THE biggest Agile project ever known is the creation of the Universe – which we know on good account was built over a 6-day sprint.

Whether you are in software development, technology, architecture, industrial design, construction; the principles are sound and they are applicable.

This post is a short guide to introduce Agile from the bottom up but the opposite can also be done – which we’ll show in a later post.

Phase 1: Pre-production

1. Aim for a quick-win – Agree to have a “Pilot” project on a small team

2. Lead the way – Select a Project Manager, one who is eager to test Agile and someone the rest of the team will want to follow in this crazy endeavour.

3. Legos are a great way to start - Break down a Project into smaller ones to test out. These will be the building blocks towards Agile… poetic isn’t it?

4. Cross-functionality – Build a small team of 3 to 5 team members. 1 Project Manager, 1 Developer/engineer, 1 Tester, 1 Designer as needed for your project. If you’re not in software development, remember it is also applicable.

5. Technology is your friend - Support your team with technological and psychological resources as needed. Shared file folder, team Wiki, chat room, comfort food, etc.


Phase 2: Iterate this!

6. Launch with a kickoff - Do an iteration “kick-off” meeting and have your team estimate their own tasks and stories.

7. Scrumfall - Keep doing what you’re already doing (waterfall, etc), but work on a 2-week cycle. This is usually called Scrumfall or Scrumbut.

8. Deliver! – Have your team deliver a complete “Product” or “Feature” or “Release” within a few iterations.

9. Wash & Repeat – Keep doing this until you have a big enough track of success to build a business case for Agile within your organization,  occasionally adding  a small team.


Phase 3: It looks Agile, it smells Agile, it talks Agile, yet…

10. Teach me master – Invest in hiring an Agile consultant and give training to some of your staff. Make a “contract” with those getting the training that they’ll have to teach at least one other team member.

11. Agile is a roleplaying game - Introduce new roles: ScrumMaster and Product Owner. The ScrumMaster’s role is similar to that of a project manager and his role is to facilitate, period. The Product Owner’s job is to Prioritize the backlog of features into  stories. He has to listen closely to the end-user to determine the right features and make sure it is usable.

12. Tools of the Trade - Introduce taskboards and daily stand-up meetings, proper Iteration kickoffs and reviews. If your teams are distributed, consider using an Agile Project Management software to simplify things. Planbox is one such software, but there are many others as well.

Overall, transitioning into Agile is an iterative process into its own. Slowly adopting Agile lingo, methods, reading about it, getting training will get you in the Agile bandwagon before you even know it.

Your team members and your users will thank you… eventually.

line