Skip to content

Feed aggregator

PMI-ACP Exam Prep with Mike Griffiths – Mind Map

Leading Answers - Mike Griffiths - Thu, 06/30/2016 - 04:41
For anyone studying for their PMI-ACP exam, I have created a mind-map of the PMI’s Exam Content Outline and my book contents. So here it is, on a single (large) page all the topics within the exam and the second... Mike Griffiths
Categories: Blogs

Product Owners and Learning, Part 5

Johanna Rothman - Wed, 06/29/2016 - 16:00

When I think of POs and the team, I think of learning in several loops:

  • The PO learns when the team finishes small features or creates a prototype so the PO can see what the team is thinking/delivering.
  • The team learns more about its process and what the PO wants.
  • If the Product Manager sees the demo, the Product Manager sees the progress against the roadmap and can integrate that learning into thinking about what the product needs now, and later.

Note that no one can learn if they can’t see progress against the backlog and roadmap.

There are two inter-related needs: Small stories so the team can deliver and seeing how those small stories fit into the big picture.

I don’t know how to separate these two needs in agile. If you can’t deliver something small, no one, the team, the PO, the customer, can’t learn from it. If you don’t deliver, you can’t change the big picture (or the small picture) of where the product is headed. If you can’t change, you find yourself not delivering the product you want when you want. It’s a mess.

When you don’t have small stories and you can’t deliver value frequently, you end up with interdependent features. These features don’t have to be interdependent. The interdependencies arise from the organization (who does what) and think they are talking about interdependencies in the features, but a root cause of those interdependencies are the fact that those features are not small and coherent. See my curlicue features post.

That means that the PO needs to learn about the features in depth. BAs can certainly help. Product Managers can help. And, the PO is with the team more often than the Product Manager. The PO needs to help the team realize when they have a structure that does not work for small features. Or, when the PO can’t know how to create feature sets out of a humungous feature. The team and the PO have to work together to get the most value from the team on a regular basis.

This is why I see the learning at several levels:

  • The Product Manager works with the customers to understand what customers need when, and when to ignore customers. It is both true that the customer is always right and the customer does not know what she wants. (I won’t tell you how long it took me to get a smart phone. Now, I don’t know how I could live without one. You cannot depend on only customers to guide your product decisions.)
  • The PO Value Team discusses the ranking/when the customers need which features. When I see great PO Value teams, they start discussing when to have which features from the feature sets.
  • The PO (and BA) work with the team to learn what the team can do when so they can provide small stories. They also learn from the team when the team delivers finished work.

The larger the features the less feedback and the less learning.

So, I’ve written a lot here. Let me summarize.

Part 1 was about the “problem” of only addressing features, not the defects or technical debt. If you have a big picture, you can see the whole product as you want it, over time. For me, the PO “problem” is that the PO cannot be outside-facing and inward-working at the same time. It is not possible for one human to do so.

Part 2 was about how you can think about making smaller stories, so you have feature sets, not one humungous feature.

Part 3 was about ranking. If you think about value, you are on the right track. I particularly like value for learning. That might mean the team spikes, or delivers some quick wins, or several features across many feature sets (breadth-first, not depth-first). Or, it could mean you attack some technical debt or defects. What is most valuable for you now? (If you, as a PO have feature-itis, you are doing yourself and your team a disservice. Think about the entire customer experience.)

Part 4 talked about how you might want to organize a Product Owner value team. Only the PO works with the team on a backlog, and the PO does not have to do “everything” alone.

If you would like to learn how to be a practical, pragmatic Product Owner, please join me at the Practical Product Owner workshop, beginning Aug 23, 2016. You will learn by working on your roadmaps, stories, and your particular challenges.  You will learn how to deliver what your customers value and need—all your customers, including your product development team.

Categories: Blogs

Product Owners and Learning, Part 3

Johanna Rothman - Thu, 06/23/2016 - 16:32

Part 1 was about how the PO needs to see the big picture and develop the ranked backlog. Part 2 was about the learning that arises from small stories. This part is about ranking.

If you specify deliverables in your big picture and small picture roadmaps, you have already done a gross form of ranking. You have already made the big decisions: which feature/parts of features do you want when? You made those decisions based on value to someone.

I see many POs try to use estimation as their only input into ranking stories. How long will something take to complete? If you have a team who can estimate well, that might be helpful. It’s also helpful to see some quick wins if you can. See my most recent series of posts on Estimation for more discussion on ranking by estimation.

Estimation talks about cost. What about value? In agile, we want to work (and deliver) the most valuable work first.

Once you start to think about value, you might even think about value to all your different somebodies. (Jerry Weinberg said, “Quality is value to someone.”)  Now, you can start considering defects, technical debt, and features.

The PO must rank all three possibilities for a team: features, defects, and technical debt. If you are a PO who has feature-itis, you don’t serve the team, the customer, or the product. Difficult as it is, you have to think about all three to be an effective PO.

The features move the product forward on its roadmap. The defects prevent customers from being happy and prevent movement forward on the roadmap. Technical debt prevents easy releasing and might affect the ease of the team to deliver. Your customers might not see technical debt. They will feel the effects of technical debt in the form of longer release times.

Long ago, I suggested that a specific client consider three backlogs to store the work and then use pair-wise comparison with each item at the top of each queue. (They stored their product backlog, defects, and technical debt in an electronic tool. It was difficult to see all of the possible work.) That way, they could see the work they needed to do (and not forget), and they could look at the value of doing each chunk of work. I’m not suggesting keeping three backlogs is a good idea in all cases. They needed to see—to make visible—all the possible work. Then, they could assess the value of each chunk of work.

You have many ways to see value. You might look at what causes delays in your organization:

  • Technical debt in the form of test automation debt. (Insufficient test automation makes frictionless releasing impossible. Insufficient unit test automation makes experiments and spikes impossible or quite long.)
  • Experts who are here, there, and everywhere, providing expertise to all teams. You often have to wait for those experts to arrive to your team.
  • Who is waiting for this? Do you have a Very Important Customer waiting for a fix or a feature?

You might see value in features for immediate revenue. I have worked in organizations where, if we released some specific feature, we could gain revenue right away. You might look at waste (one way to consider defects and technical debt).

Especially in programs, I see the need for the PO to say, “I need these three stories from this feature set and two stories from that other feature set.” The more the PO can decompose feature sets into small stories, the more flexibility they have for ranking each story on its own.

Here are questions to ask:

  • What is most valuable for our customers, for us to do now?
  • What is most valuable for our team, for us to do now?
  • What is most valuable for the organization, for us to do now?
  • What is most valuable for my learning, as a PO, to decide what to do next?

You might need to rearrange those questions for your context. The more your PO works by value, the more progress the team will make.

The next post will be about when the PO realizes he/she needs to change stories.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Blogs

Product Owners and Learning, Part 4

Johanna Rothman - Thu, 06/23/2016 - 15:05

Part 1 was about how the PO needs to see the big picture and develop the ranked backlog. Part 2 was about the learning that arises from small stories. Part 3 was about ranking. In this part, I’ll discuss the product owner value team and how to make time to do “everything,” and especially how to change stories.

Let’s imagine you started developing your product before you started using agile. Your product owners (who might have been a combination of  product managers and business analysts) gave you a list of features, problems, and who knows what else for a release. They almost never discussed your technical debt with you. In my experience, they rarely discussed defects unless a Very Important Customer needed something fixed. Now, they’re supposed to provide you a ranked backlog of everything. It’s quite a challenge.

Let’s discuss the difference between a product manager and a product owner.

Teamsandvalue

A product manager faces outward, seeing customers, asking them what they want, discussing dates and possibly even revenue. The product manager’s job is to shepherd the customer wishes into the product to increase the value of the product. In my world, the product manager has the responsibility for the product roadmap.

A product owner faces inward, working with the team. The PO’s job is to increase the value of the product. In my world, the PO works with the product manager (and the BAs if you have them) to create and update the product roadmap.

A business analyst might interview people (internal and external) to see what they want in the product. The BA might write stories with the PO or even the product manager.

The product manager and the product owners and any BAs are part of the Product Owner value team. The product owner value team works together to create and update the product roadmap. In a large organization, I’ve seen one product manager, several product owners and some number of BAs who work on one product throughout its lifetime. (I’ve also seen the BAs move around from product to product to help wherever they can be of use.)

What about you folks who work in IT and don’t release outside the company? You also need a product manager, except, with any luck, the product manager can walk down the hall to discuss what the customers need.

If you work in a small organization, yes, you may well have one person who does all of this work. Note: a product manager who is also a product owner is an overloaded operator. Overloaded people have trouble doing “all” the work. Why? Because product management is more strategic. Product ownership is more tactical.  You can’t work at different levels on an ongoing basis. Something wins—either the tactical work or the strategic work. (See Hiring Geeks That Fit for a larger discussion of this problem.)

When one person tries to do all the work, it’s possible that many other things suffer: feedback to the team, story breakdown, and ranking.

The Product Owner Value team takes the outside-learned information from customers/sponsors, the inside-learned information from the product development team (the people who write and test the product), and develop the roadmap to define the product direction.

In agile, you have many choices for release: continuous delivery, delivery at certain points (such as at the end of the iteration or every month or whenever “enough” features are done), or monthly/quarterly/some other time period.

Here’s the key for POs and change: the smaller the stories are or the more often the team can release stories, the more learning everyone gains. That learning informs the PO’s options for change.

Example.AgileRoadmapOneQuarterIn this example roadmap, you can see parts of feature sets in in the first and second iterations. (I’m using iterations because they are easy to show in a picture and because people often want a cadence for releasing unless you do continuous delivery.)

If the Product Development team completes parts of feature sets, such as Admin, Part 1, the PO can decide if Admin, Part 2 or Diagnostics, Part 1 is next up for the team. In fact, if the PO has created quite small stories, it’s really easy to say, “Please do this story from Admin and that story from Diagnostics.” The question for the PO is what is most valuable right now: breadth or depth?

The PO can make that decision, if the PO has external information from the Product Manager and internal information from the BA and the team. The PO might not know about breadth or depth or some combination unless there is a Product Owner Value team.

Here are some questions when your PO wants everything:

  • What is more valuable to our customers: breadth across which parts of the product, or depth?
  • What is more valuable for our learning: breadth or depth?
  • Does anyone need to learn something from any breadth or depth?
  • What cadence of delivery do we need for us, our customers, anyone else?
  • What is the first small step that helps us learn and make progress?

These questions help the conversation. The roadmaps help everyone see where the Product Owner Value team wants the product to go. I’ll do a summary post next. (If you have questions I haven’t answered, let me know.)

Someone needs to learn about what the customers want. That person is outward-facing and I call that person a Product Manager. Someone needs to create small stories and learn from what the team delivers. I call that person a Product Owner. Those people, along with BAs compose the Product Owner Value team, and guide the business value of the product over time. The business value is not just features—it is also when to fix defects for a better customer experience and when to address technical debt so the product development team has a better experience delivering value.

I’ll do a summary post next. (If you have questions I haven’t answered, let me know.)

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Blogs

Product Owners and Learning, Part 1

Johanna Rothman - Wed, 06/22/2016 - 18:05

When I work with clients, they often have a “problem” with product ownership. The product owners want tons of features, don’t want to address technical debt, and can’t quite believe how long features will take.  Oh, and the POs want to change things as soon as they see them.

I don’t see this as problems.To me, this is all about learning. The team learns about a feature as they develop it. The PO learns about the feature once the PO sees it. The team and the PO can learn about the implications of this feature as they proceed. To me, this is a significant value of what agile brings to the organization. (I’ll talk about technical debt a little later.)

AgileRoadmap.copyright-1080x794One of the problems I see is that the PO sees the big picture. Often, the Very Big Picture. The roadmap here is a 6-quarter roadmap. I see roadmaps this big more often in programs, but if you have frequent customer releases, you might have it for a project, also.

I like knowing where the product is headed. I like knowing when we think we might want releases. (Unless you can do continuous delivery. Most of my clients are not there. They might not ever get there, either. Different post.)

Here’s the problem with the big picture. No team can deliver according to the big picture. It’s too big. Teams need the roadmap (which I liken to a wish list) and they need a ranked backlog of small stories they can work on now.

Example.AgileRoadmapOneQuarter In Agile and Lean Program Management, I have this picture of what an example roadmap might look like.

This particular roadmap works in iteration-based agile. It works in flow-based agile, too. I don’t care what a team uses to deliver value. I care that a team delivers value often. This image uses the idea that a team will release internally at least once a month. I like more often if you can manage it.

Releasing often (internally or externally) is a function of small stories and the ability to move finished work through your release system. For now, let’s imagine you have a frictionless release system. (Let me know if you want a blog post about how to create a frictionless release system. I keep thinking people know what they need to do, but maybe it’s as clear as mud to  you.)

The smaller the story, the easier it is for the team to deliver. Smaller stories also make it easier for the PO to adapt. Small stories allow discovery along with delivery (yes, that’s a link to Ellen Gottesdiener’s book). And, many POs have trouble writing small stories.

That’s because the PO is thinking in terms of feature sets, not features. I gave an example for secure login in How to Use Continuous Planning. It’s not wrong to think in feature sets. Feature sets help us create the big picture roadmap. And, the feature set is insufficient for the frequent planning and delivery we want in agile.

I see these problems in creating feature sets:

  • Recognizing the different stories in the feature set (making the stories small enough)
  • Ranking the stories to know which one to do first, second, third, etc.
  • What to do when the PO realizes the story or ranking needs to change.

I’ll address these issues in the next posts.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Blogs

Product Owners and Learning, Part 2

Johanna Rothman - Wed, 06/22/2016 - 18:03

In Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way to get from the big picture to the ranked backlog is via deliverables in the form of small (user) stories. See the wikipedia page about user stories. Notice that they are a promise for a conversation.

I talked about feature sets in the first post, so let me explain that here. A feature set is several related stories. (You might think of a feature set as a theme or an epic.) Since I like stories the team can complete in one day or less, I like those stories to be small, say one day or less. I have found that the smaller the story, the more feedback the team gets earlier from the product owner. The more often the PO sees the feature set evolving, the better the PO can refine the future stories. The more often the feedback, the easier it is for everyone to change:

  • The team can change how they implement, or what the feature looks like.
  • The PO can change the rest of the backlog or the rank order of the features.

I realize that if you commit to an entire feature set or a good chunk for an iteration, you might not want to change what you do in this iteration. If you have an evolving feature set, where the PO needs to see some part before the rest, I recommend you use flow-based agile (kanban). A kanban with WIP limits will allow you to change more often. (Let me know if that part was unclear.)

Now, not everyone shares my love of one-day stories. I have a client whose team regularly takes stories of size 20 or something like that. The key is that the entire team swarms on the story and they finish the story in two days, maybe three. When I asked him for more information, he explained this it in this way.

“Yes, we have feature sets. And, our PO just can’t see partial finishing. Well, he can see it, but he can’t use it. Since he can’t use it, he doesn’t want to see anything until it’s all done.”

I asked him if he ever had problems where they had to redo the entire feature. He smiled and said,

“Yes. Just last week we had this problem. Since I’m the coach, I explained to the PO that the team had effectively lost those three days when they did the “entire” feature instead of just a couple of stories. The PO looked at me and said, “Well, I didn’t lose that time. I got to learn along with the team. My learning was about flow and what I really wanted. It wasn’t a waste of time for me.”

“I learned then about the different rates of learning. The team and the PO might learn differently. Wow, that was a big thing for me. I decided to ask the PO if he wanted me to help him learn faster. He said yes, and we’ve been doing that. I’m not sure I’ll ever get him to define more feature sets or smaller stories, but that’s not my goal. My goal is to help him learn faster.”

Remember that PO is learning along with the developers and testers. This is why having conversations about stories works. As the PO explains the story, the team learns. In my experience, the PO also learns. It’s also why paper prototypes work well. Instead of someone (PO or BA or anyone) developing the flow, when the team develops the flow in paper with the PO/BA, everyone learns together.

Small stories and conversations help the entire team learn together.

Small features are about learning faster. If you, too, have the problem where the team is learning at a different rate than the PO, ask yourself these questions:

  • What kind of acceptance criteria do we have for our stories?
  • Do those acceptance criteria make sense for the big feature (feature set) in addition to the story?
  • If we have a large story, what can we do to show progress and get feedback earlier?
  • How are we specifying stories? Are we using specific users and having conversations about the story?

I’ve written about how to make small stories in these posts:

The smaller the story, the more likely everyone will learn from the team finishing it.

I’ll address ranking in the next post.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Blogs

The Diagnosis and Treatment of Bimodal IT

Leading Answers - Mike Griffiths - Thu, 05/26/2016 - 05:35
Is it just me, or does Bimodal IT sound like a mental health condition? Unfortunate name aside, it has been adopted by companies reluctant to embrace agile but looking for a halfway-house / best-of-both-worlds solution. In my last post I... Mike Griffiths
Categories: Blogs

Agile Coach Camp

Leading Answers - Mike Griffiths - Thu, 05/19/2016 - 02:38
I attended this event last year and enjoyed it... We would like to invite Agile Practitioners to Agile Coach Camp Canada - West, an Open Space Conference to be held in Vancouver, BC on the weekend of June 17-19, 2016.... Mike Griffiths
Categories: Blogs

PMBOK v6 Work

Leading Answers - Mike Griffiths - Thu, 05/19/2016 - 01:52
As you probably know the Exposure Draft of the PMBOK v6 Guide is making its way through review at the moment. I have been working with the PMI on some iterative, adaptive and agile content and look forward to when... Mike Griffiths
Categories: Blogs

DSDM Video

Leading Answers - Mike Griffiths - Thu, 05/19/2016 - 01:47
I get the feeling that DSDM is considered by many people outside of the UK as the uncool, out-of-touch great-uncle of agile. While somewhat related to modern agile, it is kind of forgotten about or dismissed as outdated or not... Mike Griffiths
Categories: Blogs

Speaking at ISIPM – Agile Project Management Event

May the 18th in Rome, I am giving a speech and participate to the final roundtable, at the event organized by the ISIPM (Italian Institution of Project Management) called “Agile Project Management”. I will be speaking on how to increase the percentage of success of any Agile transition, by adopting an adequate approach to Change Management. The […]
Categories: Blogs

[Recap] Fast IT: Concepts and Examples from Assembla and Attivio

Assembla Blog - Thu, 07/31/2014 - 22:51

Last week, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla presented a webinar about “Fast IT,” a new way of managing rapidly changing and Agile projects in areas like mobile, Web, analytics and marketing applications, while working smoothly with reliable core systems ("Core IT"). Andy discussed the dynamics of Fast IT, and Sid presented a case study of how Attivio spun up a major Business Intelligence app in two weeks with two people.

If you missed the webinar, view and download the slides

Want an overview of Fast IT in 60 seconds? Watch the video below:

Get notified about new and exciting content around Fast IT by completing the form below:

//

Categories: Companies

Assembla now allows automatic payments with PayPal

Assembla Blog - Fri, 07/25/2014 - 20:17

Paying for your Assembla subscription with PayPal has never been easier. We recently added the ability to set up recurring payments with PayPal that will automatically pay for your Assembla subscription every billing period, whether that be monthly or annually. Previously, it was a manual process that required logging in and paying every time an invoice was created.

To set up automatic payments with PayPal, visit your billing page > select the PayPal option > and follow the steps.

assembla paypal option1

If you have any questions or issues, please contact Assembla support at support@assembla.com.

Categories: Companies

Post Assembla events to your favorite chat apps: Slack, HipChat, Flowdock & more

Assembla Blog - Wed, 07/16/2014 - 02:26

If your team uses Slack, HipChat, Flowdock, or Bigplans for communication, we have added preconfigured webhooks to make setting up these integrations painless. Once configured, you can selectively manage the Assembla events that are posted out to these apps, such as ticket activity, commits, deploys, etc., to monitor project activity in real-time, inline with other team communication.

To get started, click on the desired integration below: slack logo HipChat Logo flowdock logo Bigplans logo
Categories: Companies

Interested in cryptocurrencies? Get started with 1000 free Ripple XRP

Assembla Blog - Tue, 07/15/2014 - 20:55

ripple logo

Ripple is a protocol for value exchange that makes it easy to transfer and trade fiat currencies, Bitcoin, or XRP - the native asset of the Ripple network.

Assembla is giving away 1000 free XRP (the Ripple native cyptocurrency) to any person with software development skills who is interested in learning about Ripple development. Get it here: https://www.assembla.com/ripple

I called Ripple Labs a few months ago to find out more about ways that their "gateway" can help us pay developers in many different countries. Essentially, we do banking for the developers on our global team. We pay internal accounts, hold the money until they ask for it, and then transfer money to them by bank wire, ATM/Payoneer, or other mechanisms. We have found that the bank wire system is embarrassingly slow and unreliable. This is the problem that Ripple is trying to fix. Their gateway is like a bank in an open-source box. It keeps accounts in any currency, including USD, other currencies, XRP, and Bitcoin. It can transfer those accounts instantly and reliably on the shared "ledger." It is also gaining exciting new features such as "multi-signature" which enables outsourcing and crowdsourcing customers to post a budget amount, and then transfer it to their hard-working suppliers through an arbitrator.

Now I am working more closely with Ripple to help them scale up their development process. I decided to make this free XRP offer for two reasons:

  • Users need 20 XRP to activate a Ripple wallet. We want to remove the hassle from acquiring the XRP so new developers can get started.
  • We want to build an email list of developers that might be interested in working on internal development, bounties, or bank integration projects.
ripple blog CTA
Categories: Companies

Assembla Bigplans Integration How-To

Assembla Blog - Tue, 07/15/2014 - 18:26

If you use Assembla and Bigplans, we have added a pre-configured webhook making it easy to post Assembla events out to your Bigplans chat room. Check out below for configuration instructions.

Bigplans is a simple, integrated way to manage a distributed team.  It includes a "lean" task board, real-time chat, and a unique "advisor" (a real person) that helps you get on-demand resources if you need them.  For programming teams, it includes a tight integration with Assembla login and Assembla tickets. 

You can use the Webhooks tool to feed Assembla events into any of your team chats.  To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.

Once installed, click on the Webhook tool in your main navigation and select Bigplans from the list of pre-configured post options:

Bigplans Assembla Webhook

You will need to obtain and update the auth token in the “Content” section.

To obtain your Bigplans auth token:

Visit Bigplans and navigate to the plan you want to post Assembla events to. Click on the ‘Connect’ option in the top bar. Under the “Message API” section, there is a section called “API Token” that will display your token. If no token is set, click on the ‘Reset’ button. Copy the token ID and replace the “BIGPLANS_AUTH_TOKEN” in the Webhook tool.

Bigplans Assembla Webhook Token

Now configure what Assembla events you would like to post to your Bigplans chat room and click ‘Add and Authenticate.” Don’t forget to enable the configuration under the “Title” field.

Your Assembla events will now be posted to the configured Bigplans chat room:

Bigplans Assembla Webhook Chat

If you have any questions or problems during setup, please contact support@assembla.com. If you do not have an Assembla project and would like to test out this integration, try Assembla out for free.

Categories: Companies

Assembla & Slack Integration How-To

Assembla Blog - Tue, 07/15/2014 - 14:23

If you use Assembla and Slack, we have added a pre-configured webhook making it easy to post Assembla events out to your Slack chat room/channel. Check out below for configuration instructions.

To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.

Once installed, click on the Webhook tool in your main navigation and select Slack from the list of pre-configured post options:

Slack Assembla Webhook

You will need to setup an incoming webhook service integration within Slack to obtain your token. To do this, visit https://YourSubdomain.slack.com/services/new/incoming-webhook, select the desired channel to post to, and click ‘Add Incoming Webhook.’

describe the image

Once created, copy the provided Webhook URL and update the External URL in Assembla’s Webhook tool.

Now configure what Assembla events you would like to post to your Slack room/channel and click ‘Add and Authenticate.' Don’t forget to enable the configuration under the “Title” field.

Tip: Within the Slack “Incoming Webhook” page that you set up for this integration, you can scroll to the bottom of the page and expand the “Integration Settings” where you can add a label, change the post-to channel, and change the icon and name for your webhook bot.

Your Assembla events will now be posted to the configured Slack room/channel:

describe the image

If you have any questions or problems during setup, please contact support@assembla.com. If you do not have an Assembla project and would like to test out this integration, try Assembla out for free.

Categories: Companies

Assembla & HipChat Integration How-To

Assembla Blog - Tue, 07/15/2014 - 13:40

If you use Assembla and HipChat, we have added a pre-configured webhook making it easy to post Assembla events out to your HipChat chat room. Check out below for configuration instructions. 

To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.

Once installed, click on the Webhook tool in your main navigation and select HipChat from the list of pre-configured post options:

HipChat Assembla Webhook

You will need to obtain and update the auth token and room ID in the “Content” section.

To obtain your HipChat auth token:

You will need to visit https://YourSubdomain.hipchat.com/admin/api and enter your password to access the “API Auth Tokens” page. Under “Create new token” select ‘Notification’ type, provide a label, and click ‘Create.’ Copy the token ID and replace the “HIPCHAT_AUTH_TOKEN” in the Webhook tool.

describe the image

To obtain your HipChat room ID:

Visit https://YourSubdomain.hipchat.com/admin/rooms and click on the desired room you would like to post Assembla events to. Copy the App ID and replace the “HIPCHAT_ROOM_ID” in the Webhook tool.

describe the image

Now configure what Assembla events you would like to post to your HipChat room and click ‘Add and Authenticate.” Don’t forget to enable the configuration under the “Title” field.

Your Assembla events will now be posted to the configured HipChat room:

HipChat Assembla Example Chat

If you have any questions or problems during setup, please contact support@assembla.com. If you do not have an Assembla project and would like to test out this integration, try Assembla out for free.

Categories: Companies

[Webinar] "Fast IT": Concepts and Examples from Assembla and Attivio

Assembla Blog - Fri, 07/11/2014 - 17:41

Join us on July 23, 2014 from 11:00 AM - 11:45 AM EDT for a webinar “Fast IT”: Concepts and Examples from Assembla and Attivio.

describe the image

When we at Assembla heard about the 2-2-2 project structure used by Attivio, we knew we had a fun story and a big idea to share.  The fun story is the way that Attivio can spin-up major Business Intelligence apps with 2-day, 2-person prototyping sessions. The big idea is “Fast IT”: a way of managing fast and Agile projects, while working smoothly with your slower, more reliable core systems: "Core IT".

In this Webinar, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla, will share their discoveries about ways that “Core” and “Fast” can work smoothly together.  We will show tools that help you wrap and index your Core IT so that you can easily use it in Fast IT projects.  And, we’ll show how to professionally launch and manage an expanding portfolio of Fast IT projects for analytics, Web, mobile and marketing applications and SaaS integration. 

This Webinar is designed to help IT professionals or project managers who are handling analytics, Web, mobile, cloud and marketing applications.

describe the image

Presented By:

assembla logo rectangle    Attivio logo

Categories: Companies

Success Story: GLG Boosts “Customer Equity” with Assembla

Assembla Blog - Tue, 06/24/2014 - 17:25
GLG Logo Challenge

Garrigan Lyman Group was worried about losing the loyalty of its own customers. The agency was expanding rapidly and tackling more complex e-commerce, mobile, social media and video projects. Clients had no visibility into when new requests would be delivered. Development managers were having trouble tracking releases and matching resources to requirements. Teams needed a solution to prevent missing deadlines and ensure the quality of delivery.

Objective

Chris “Whitey” Geiser, GLG’s CTO, knew that the agency could not afford to lose “customer equity,” the hard-won confidence that GLG could deliver innovative digital marketing solutions. So he and his team began looking for technologies that could help them centralize processes, manage development requests, and improve communications with clients.

Results

Assembla has helped Garrigan Lyman Group win new business from existing clients. The solution has helped GLG evolve from helping clients with flashy but self-contained marketing projects, to solutions that work with the core of their businesses. It allows the company to collaborate better with clients and improve control of their development processes.

To see how GLG learned to work more closely with its customers,
fill out the form below to download the full case study.

//

Categories: Companies

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.