I’ve used plenty of project tracking tools over the years many of which I detested and a few I was OK with. AgileZen was a pleasant surprise when I came across it and I wrote a review and lobbied for using it at my current company as a Kanban style lightweight tool. It worked fine for us for a year or so, but gradually we noticed it was getting no love. The UI in tools like Pivotal Tracker were getting more responsive and event driven and AgileZen was stuck in the old request response cycle with a smattering of AJAX. Eventually it was obvious to us that it was dead software walking.
Rally Software promised that the beta would improve everything, but in the end they never released it. I’m sure it was a business decision where they didn’t see enough upside in improving it and decided to just eke out a profit with the current dwindling subscribers.
We ended up back in Pivotal Tracker which has served us well, but I still wish there was a nice Kanban style replacement for AgileZen.
Call Amy Ayres a developer, a darned genius, a hard worker, or a problem solver, just don’t call her a pioneer. Because she doesn’t really feel that gender problems exist in the tech space. Before you start thinking things like, “wait, what? There are issues! We have a gap that we need to contend with! Our girls are not encouraged to like math and science!” please read on…Amy Ayres at Axosoft
It is obvious that Ayres, an Axosoft developer, who sits in a coding room with about 15 men every day, has always been a standout. The key, Ayres says, to being in a male-dominated industry is simply a strong foundation and confidence. And of course, brainpower.
“I was lucky that we had a computer at home back when most people didn’t,” explains Ayres. “There was one computer class offered in my high school and even though it was a bit easy for me, the teacher let me do what I wanted.” In elementary school, Ayres had an Apple IIe which came with a “handful of books and some simple games.”
This explains a lot since Ayres is satisfied to work on her own, do her own thing and pretty much be content with the fact that she is more than holding her own in that male-dominated Dev room. After spending some time with her, you have to completely believe that confidence is the key.
“When I was in third grade, I got in trouble for something and a teacher wanted me to write 100 times, ‘I will not…..whatever infraction I committed.’ So instead of writing it, I wrote 4-5 lines of code that simply printed the text 100 times.” The teacher was a bit miffed but impressed, she conveys.
Ayres feels that having determination along with a strong, supportive foundation definitely set her up for success. This seems obvious, but she comes from two parents who knew what kind of brainpower they were dealing with and how to help her realize success. Her father was a network engineer at a university and her mother was a math major who later taught computer science at a community college. Reflecting on her childhood, Ayres says,
“One of the best things my parents did for me was to not help at all. I had to solve my own problems and became a very independent person.”
Once Ayres was enrolled in college she landed on computer science as a major. If that didn’t work out, plan b was electrical engineering. When asked if anyone tried to talk her out of it, the look on her face is one of are you kidding me?
“When you’re doing 8th grade math in the 6th grade, you pretty much know where your strengths lie—regardless of your gender,” she says, “just do what you’re good at and know where your heart is.”Amy Ayres
It’s clear that Ayres was in her own echelon as the top female and among the top students—and completely comfortable there—even in elementary school. But what advice does Ayres have for students who may not be in the very top of their class and a little unsure about their math or technical skills or bothered by ‘the gender issue?’
“It hurts nothing to try. Try and you’re going to gain problem-solving skills, which will help you no matter what. Even if it doesn’t work out at some level, you’ve still gained those skills. And you may decide to change. But you haven’t lost anything. You can use those skills for any career,” she says.
“It’s really not about boys versus girls,” she adds. “It’s whether or not you’re good at it. Everyone should do what he or she wants to do. Don’t do something you think you should do just to please others. Just follow your heart.”
We know through research that girls enter a particularly fragile period between the ages of 12-17. This is when their confidence can be swayed and when they can be susceptible to outside influences.
“This is when I think some girls get pressure to not be seen as a nerd.”
Ayres reflects specifically on her own two children. She tried to always make sure they got enough support. “If your home life is strong, you can stand up for yourself out in the real world more easily.”
It then follows that if a female finds herself in the tech industry, they will be confident enough to address any issues they see, including discrimination.
“You don’t want to work for people who are going to discriminate against anyone,” explains Ayres. “I just look at that as an additional screening process for me. Discrimination is a good indicator of a bad work environment,” she explains.
So, what do females in tech positions do differently than men? “I think some women tend to try harder simply because at some places they do have something to prove. I’ve had some friends finish degrees and work at the same time, even though the degree was not 100% necessary,” Ayres explains. Although this is just an anecdote, it shows that the tech space is a human space where heart, passion and risk-taking are necessary. It doesn’t matter what your gender is as long as you’re driven.
If you’d like to learn more about creating a culture for women in tech—including how to hire and retain qualified and diverse talent—register for our upcoming webinar on October 21st at 11am PDT.
A couple of weeks ago, I had a great time participating in the Agile in Large Enterprises panel, a part of the Continuous Discussions (#c9d9) that Electric Cloud hosts.
Here’s the recording:
We discussed these questions:
- Why agile in large enterprises and what are the challenges?
- Where should you start?
- Centralized? Decentralized? Where should agile live?
- What is the one thing enterprises should do?
I had a number comments, which you should watch to see the entire context:
- Agile requires cultural change.
- Start with the people who want to change.
- Agile should “live” everywhere.
- Automate everything. And, retrospect to learn from what you have done and what you could do.
I had a terrific time along with my fellow panelists.
As an Agile Coach, I have many stories of outright failure, misguided intentions and other disasters to share. Periodically I share these tales, both as a warning to those teams that don’t follow advice and to explain my battle scars from teams past. I also have many stories of success and satisfaction. I want to share one of these success stories with you, even though I wasn’t present and a team did something interesting on their own.ScrumMaster OOO
Today, one of the ScrumMasters in a program I am coaching to Basecamp 1 was out of the office. The team felt they could do their Sprint Review at 1:30 on their own, but asked if I would facilitate their Sprint Retro at 2:30. I obliged.
At the appointed time, I arrived to facilitate a Retrospective I was greeted with a chorus of, “we finished at 2:00 and didn’t wait for you, sorry!” Apparently, the Sprint Review was rather quick; they held a Retro on their own and were now elbows deep in an impromptu Backlog Grooming session with the remainder of the time they had scheduled together.
As I reached into my bag for the pile of sticky notes I brought, the narcissistic devil on my shoulder started an inner dialogue something like this: “You did a Review and Retro in 30 minutes? You did it wrong. I rescheduled another meeting for this Retro. I walked 4 blocks from where I was to your building for this. I am really good at this. I’ve been facilitating Retrospectives since some of you were in High School. You’ve only been doing this for 3 Sprints. I think you need me to do it the right way. We’re going to do it again, my way.”
Thinking I was standing there in awkward silence for too long, one of the developers chimes in with “We feel the lack of backlog depth is our biggest issue and is the root cause of a few other problems we experienced this Sprint, so we are doing backlog grooming for the rest of the afternoon.”
What’s this? A developer talking to me? Telling me there is a problem with the Backlog? Where is the Product Owner? I want to see their face turn red and start a fight! Oh wait, there she is… smiling? No fight? A Developer and the Product Owner agree? Something is really wrong here.
Before I could embarrass myself in front of the team, Coaching Angel pops up on my other shoulder and shoos off the devil with a reminder: “Hey, really? This team, sans ScrumMaster, successfully facilitated a Retro, identified an impediment and immediately started to work on resolving the impediment. Smile and put the stickies away.”Teams Taking Ownership
I’m certain nobody on the team was looking forward to an impromptu afternoon of backlog grooming when they woke up this morning. And I’m impressed that a team, even without formal leadership and facilitation from a ScrumMaster, took ownership of doing what we typically require as Scrum Ceremonies, took it a step further, and acted in the best interest of the business and their trek toward Basecamp 1 to dig right in and start working on the biggest issue they identified a half-hour earlier.
I can’t wait to see how the ScrumMaster reacts to this news tomorrow.
As their Coach, I couldn’t be more proud. And I was happy to spend an extra hour averting the next potential disaster.
- The team reports to the Scrum Master at the Daily Scrum
- People wait for instructions from the Scrum Master
- Team members don't hold each other responsible [for their commitments]
- The same impediment comes up twice
- "That's the way it is" => resignation
- "I" instead of "We"
- Flip charts are lonely
- Culture of conflict-avoidance
- Decisions processes are unclear, nor are they discussed
- Personal goals are more important than team goals
To this list I would add my a couple of my favorites:
- you don't see a triangle on the task board (not working according prioritization of stories)
- after the daily Scrum, people return directly to their desks (no collaboration)
- there are a least as many stories in progress as team members (no pairing)
P.S. You can join the discussion or solve your own challenges at a future event! And here is the original list (in German).
EDIT: Here is the second slide:
- Retrospectives are superficial
- Agile Mindset Not Present => No inspect and adapt
- The Team has no influence on the backlog (order, content, priority)
- The Team is not interested in improving their performance
- Changes in Team Composition are not managed by the Team
- New members are not introduced by the whole team
Targetprocess 3 provides powerful DSL filters, which allow users to compose very sophisticated queries against their data. However, this flexibility increased the level of complexity to filter in the product and even advanced users needed some time to learn the filter language. To help users get started and make the filters easier to understand, we’re happy to introduce a new feature – Visual Filters.
Now it’s much faster and easier to create queries. When you enter the input field a dialog immediately appears with a list of possible filters for your data. This filter list has many of the fields you’d normally get from the auto-suggestion when manually typing ‘?’ into the input.
With the first release of this feature, you will be able to use the visual filters for the most common filters. It’s not meant to be a complete replacement of advanced queries.
Let’s say you want to see all the cards from the current release. Click in the filter box, and the new visual filters will display automatically. Then click the grey “Any” text next to release and you will see a list of choices to filter releases by. Choose one, and it will be immediately added to the filter.
When you’re done building the query, just click the “Apply filter” button to filter the cards.Fixed Bugs
- 109044 Fixed: Requests not created if email subject contains \r\n
- 109560 Fixed: error message layout on a Quick Add Release form
- 110375 Fixed: broken links of type [name](<url>) in Markdown
- 110601 Fixed: Stuck at loading mashups with Microsoft Edge Browser
- 110910 Fixed: the list of Projects/Teams for a custom shared View when it moved to a custom shared Group
Recently new models have began to emerge for how different organizations, especially larger, legacy organizations are approaching managing their projects, programs and portfolios. Over the next few posts I will be highlighting key aspects of a few of these “new” models, while pointing out key differences. I am also hoping to record a few podcasts on this topic, so please keep an eye on our Sound Notes for updates.
Before digging in, there are three things I’d like to establish first:
1. When I say “new”, I don’t mean new as in something we have not seen before. For this post, “new” is a little more like, “put together in a way that let’s us give it a shiny new name and pretend this is something we’ve not seen before”. I don’t think that is a bad thing, but I think the newest part to these “new” models is usually their name.
2. The building blocks for all of this are traditional (waterfall) project management, a variety of flavors of Agile and Innovation capabilities (i.e. Lean Startup, Innovation Centers, etc.)
3. I am writing this both to explore new models and to clarify my own understanding as I attempt to share information. Any feedback, comments, thrown shoes, etc. are welcome and encouraged.
This post will focus on what many people refer to as “Hybrid Agile” (or any of the other names where they push waterfall and Agile/Scrum/whatever together).
And in the beginning there was waterfall.
And some folks said it was good.
Other folks said it was really awful and they created Spiral.
And the Spiral folks said it was good.
And other folks looked at Spiral, shrugged and said “Meh.”
And they created Agile.
And the Agile folks said it was good.
And then there were the banks…
…not just the banks, but any archaic organization steeped in hundreds of years using traditional ways of approaching work. They liked the idea of Agile, but it was really hard to make that massive a change.Enter The HYBRIDS
For the purposes of this series of posts, Hybrids will refer to any mix of methodologies and frameworks with the desired end state of having a customized, or tailored approach to managing work in an organization.
For the past two years, I have been leading PMI workshops on how to establish a “hybrid” PMO. I have learned that when people talk about “hybrid” models of managing work, more often than not, they are talking about one kind of hybrid and doing another. They talk about a Conscious Hybrid approach in theory, but practice an Unconscious Hybrid approach with their actual work.Conscious Hybrids
In a Conscious Hybrid organization, the mix of processes evolves over time. This is done by running experiments with the goal being continuous improvement of the way an organization is approaching work. The key factor here is that specific experiments are defined and run in order to test hypothesis about what might happen if a certain practice is introduced into the workflow and given time to stabilize. Once this has happened, the change is evaluated and kept or abandoned depending on the results.
For example, a traditional organization might decide that it wants to test out mob programming to see how it impacts the organization. A team (or teams) prepare for the experiment by learning about mob programming, an initial assessment is done to try and understand how it will impact other parts of the organization and then the test is run. Once the team has had time to get their legs with mob programming, management has seen the results and the rest of the organization has felt the impact and understands the ramifications, then a decision will be made to adopt or abandon mob programming.
It is important to keep in mind that this is not a decision that can be made by the team alone. Every part of the organization that is impacted by this test should weigh in as well.
Another example of this in the LeadingAgile model occurs during Basecamp 1, when we stabilize the system by establishing stable teams that can make and meet commitments. We start by working with organizations where they are and help them make a conscious choice to begin introducing Agile methods to understand the impact these approaches will have on their existing system.Unconscious Hybrids
Unfortunately, this approach is far more common. In an unconscious hybrid, a new approach is evaluated and a decision is made to adopt part of the approach. It is very important to keep in mind that this is usually done with the very best of intentions.
Each organization feels that it is different and has truly unique challenges not accounted for by standardized frameworks. So, an organization may take a look at something like Scrum and decided that they like the idea of working iteratively in short cycles and frequently delivering work to solicit feedback, but they may be unwilling to envision how their organization could possibly operate with individuals dedicated to a single team and/or project. So, they decide to adopt Scrum, but switch people around on teams and project at the start of each Sprint. This is a decision that is normally made without testing the alternative.
The difference between the two options above is that in the former, through investigation, a decision is made to incorporate a different approach into an existing approach. In the latter, a decision is made to adopt only a portion of a system without understanding how leaving part of it behind will impact the use of that approach.
In my own experience I have formed an opinion that there is nothing inherently bad about a “hybrid” approach to work. But there is something inherently dangerous about an unconscious hybrid approach to work. Regardless of how Agile we are, being more mindful about how and why we work is always going to elicit better results for ourselves and our clients.
In the next few posts I will be focusing on Organizational Agility and the Bi-modal approach.
It’s quite common for a team to have a bit of unfinished work at the end of an agile sprint or iteration. Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case. This leads to a couple of questions I’ll address here:
- What should be done with the product backlog item itself?
- Should be it split or should it be carried it into the next sprint? Should the team receive any velocity “credit” for completing a portion of the story?
When a product backlog item is not finished at the end of an agile sprint, it should first technically be put back onto the product backlog. Work never moves automatically from one sprint to the next.
I’m perhaps being overly pedantic here, but the point is that each sprint begins with the product owner making a conscious, deliberate decision about what the team should work on. If there’s unfinished work from the prior sprint, it’s very likely the product owner will want the team to finish that work in the new sprint. But, the product owner should still make an actual decision to do that.
(As a note, let me also say that I’m not suggesting you make extra work for yourself if you are using a tool that would make this difficult. All I’m saying is that work does not automatically move into the next sprint. The product owner must decide if the work is still valuable.)Splitting or Carrying the Item Forward
When a product backlog is unfinished, teams are often torn on whether they should leave the product backlog item description alone (even though part of that functionality might be complete) or rewrite it to describe just the missing piece.
For example, consider a team building typical print preview functionality in a desktop application. If the team builds everything but the ability to page backward through the pages, it can either carry forward the original user story or write a smaller, replacement story like, “As a user, I can page backward while on the print preview screen.”
I recommend that if you are going to finish the story in the coming sprint, just leave it alone. Don’t rewrite it. Everyone is used to it as it’s written. Assuming it’s still of value to the product owner, it moves forward exactly as written.
However, if the remaining work will be deferred to a later sprint, write a new story that describes just that subset of functionality. IMAGE QUOTE: If you’ll finish in the next sprint, don’t rewrite the story.Does the Team Earn Velocity Credit
I always want to take a conservative stance towards calculating velocity. This means that a team should only take credit for work that is truly complete.
So, in the case the unfinished product backlog item is rolling forward to be completed in the next agile sprint, do not take any velocity credit. The team instead earns all credit in the sprint in which the work is finished. Since I advocate working with average velocities anyway, this averages out and avoids the risk of overstating velocity.
But when the team splits the story and puts the remaining subset onto the product backlog to be done in the future, go ahead and take some amount of velocity credit. The team will need to do its best to estimate a fair number of points for the subset of work that was completed. And, even though it did not finish the entire original story, the team may give itself all the original points if it feels the story was larger than originally planned. I’d be reluctant to do that very often. But, it is OK.Always Look for a Root Cause
Finally, whenever work is unfinished at the end of an agile sprint, the team should take time in the retrospective to consider whether it was caused by something preventable. Sometimes, it’s just bad luck or bad timing, such as a team member becoming ill or a problem being found late in the sprint that could not have been found earlier. But, it’s always worth considering whether there is a root cause and whether something can be done to prevent it from affecting future sprints.What Do You Do?
How do you handle work left at the end of the sprint? And have you found good ways of minimizing how often you have work left unfinished at the end?
Last night our Lego Mindstorms robot “Robit” somehow managed to win the Robot Sumo competition at the GOTO conference in Copenhagen!
Pretty frickin’ amazing considering that this was a big software development conference with lots of super-experienced developers competing, and our robot was mostly built by two kids – David and Jenny Kniberg (11yrs and 10yrs old) – the only kids at the conference. Their robot didn’t just win once – it outmaneuvered and outwrestled the competing robots in every match!
Here’s the final, Robit to the left:
So how could a newbie team win the competition so decisively?
Was it our robot-building skills? Definitely not. We build mindstorm stuff maybe 1-2 hours per YEAR. We are newbies.
Was it our coding skills? Probably not. We do have experience coding. But very little in Mindstorms. And this was a professional software development conference, so we definitely didn’t have the upper hand on coding skills.
Was it luck? Nope, blind luck wouldn’t help us win every match in such a decisive way.
Was it because we (the adults) work at Lego? Nope. Didn’t use any special parts, didn’t consult with any experts.
So what was it then?
A clear goal, a bit of research, and lots of integration testing!
First we set a goal. I wasn’t too optimistic – we’ve never done anything like this before, and I expected tough competition. So my suggestion was “Let’s built a robot that at least can stay in the ring and put up a fight!” So if/when we lose, it should not be because our robot ran itself out of the ring. Kids didn’t accept that – they said “No way. We’re gonna WIN!”.
Nevertheless, I convinced them to start in small steps. “How about you START by building a Minimum Viable Robot – one that can just move around the ring without falling out. Then keep testing and improving from there”. Agile, anyone?
We knew nothing about these kind of competitions so we started by looking at some youtube clips to see what kind of designs and strategies people were using. That gave us some ideas.
Dave invented his own robot from scratch and figured out how to program it to stay inside the ring. We weren’t sure how good it was at fighting though, so Jenny built us a second robot to use as sparring partner, the mindstorms base robot from the building instructions.
Upon integration testing in a makeshift ring, it became apparent that our first robot can’t win. It could navigate the ring beautifully, but it was simply too weak physically to budge the other robot.
So now we had a SmartBot (smart but weak) and a ToughBot (strong but stupid). We figured it’s easier to make the ToughBot smarter than to make the SmartBot tougher (because of the base construction). Plus we really are newbies at building these things, so we figured we’re best off using the default mindstorms bot as a base.
After installing some sensors and porting some of the code from SmartBot, our ToughBot was becoming a ToughSmartBot! We had our candidate! Robit was born! Time to train him up. The original SmartBot was gradually stripped of sensors and stuff and became DummyBot – our training dummy.
We gave ourselves a very concrete challenge – Robit must learn to beat DummyBot! Not just once, but repeatedly. Because if Robit can’t beat a weak stripped down half-broken robot that stands still or roams around randomly, how could it have a chance in the competition? So we went through a bunch of cycles of integration testing and tweaking the hardware and software. We kept failing over and over (often in funny ways), but every iteration we got a bit closer to winning. It was 100% learning by experimenting.
One interesting thing happened along the way. We noticed on the youtube clips that many robots tried to lift and topple their enemies. So Dave built a pretty elaborate construction for that, and I helped write the code to control the lifter. Upon integration testing though, to our surprise, it turned out that the lifter wasn’t strong enough to lift the DummyBot under any circumstances. We would need another motor to strengthen it and we didn’t have the patience to figure out how. Bummer!
So with some regret we removed all hardware and code related to that. In theory it was awesome, in practice it was useless. We wanted to keep Robit simple and focused on one thing – putting up a proper fight!
I hate to admit it, but I really didn’t think we would stand a chance at winning the competition, so my ambition level was really just to have a robot that would put up a fight before losing. I didn’t want to ruin the kids hope though, so I kind of kept that to myself.
After dumping the lifter, Jenny built a simpler solution based on a pic we found online – a simple static bulldozer-like slope at the front of the bot. We figured that would help us get under the wheels and push or topple the opponent. Nothing unique, most robots have something like that in the front.
More integration testing. Started working pretty nice, Robit could now push the DummyBot around! However it was hard to get the right angle of attack. So the software needed some work.
After lots of iterating, Robit ended up with the following winning formula:
- Start by driving forward and right for 2 seconds. That takes me a bit away from the line of sight of the other robot, and protects me from blind stupid robots that just charge without looking. Also gives me a better attack angle towards the side and rear of the opponent.
- Main loop (the proactive “win the game” loop)
- Turn clockwise until I see the opponent
- Attack as long as I see the opponent! The attack sequence is “move forward 3 seconds, then move back 1 second”.
- Secondary loop (the reactive “get me out of trouble” loop)
- Am I at the edge of the ring (color sensor sees white/blue ground)? If so interrupt the main loop and BACK UP!
- Is someone pushing me from behind (button sensors on my butt)? If so interrupt the main loop and BACK UP!
That’s it. A simple algorithm that turned out to generate a pretty advanced behaviour! During the actual competition, Robit managed to outmaneuver most opponents and keep hitting them from the side, and thereby avoid their weaponry. The “backup 1 second” part of the attack sequence was important because robots often get stuck in a deadlock while wrestling. By backing up and getting reoriented, Robit could turn and attack again and again, with new momentum each time. Once it even flipped a much heavier opponent on it’s head!
Here’s another example of a match – took about 10 seconds to outmaneuver and push out the opponent!
We were four people in the team – Dave and Jenny, me, and Lars. Although both Lars and I work at Lego (he is an employee and I am a part-time consultant), both of use are Mindstorm rookies. Due to time constraints Lars wasn’t able to participate in building or programming the robot, but during the competition he discovered that Robit had been damaged. If he hadn’t noticed and fixed that, we definitely wouldn’t have won.
As for my role, well, it was mostly coaching. I did end up writing most of the code, but that was in tight collaboration with the kids. Plus it wasn’t really that much code, once we figured out a good algorithm.
The big learning for me is how incredibly important and powerful it is to iterate fast! And to do end-to-end integration testing early and often. The usual agile stuff in other words.
We ended up with a robot that was mechanically one of the most simple ones in the tournament, and software that was also pretty simple but very well tested. So when Robit entered the arena he was already an experienced battle-scarred combatant! Robit kicked butt!
Here’s the source code – or “Robit’s Brain”
Initially I was hesitant to give it away, since we might compete again. But giving it away forces us to improve! So if we build another robot, it’s qualification test is if it can beat Robit in the test ring
One of the first things we recommend new Agile teams establish is what’s called the “Definition of Done”. The DoD is crucial to highly functioning Agile Teams in helping them develop practices and behavior that drive quality, consistency and transparency.Why it matters
A useful product has two key aspects. Features in this product are [...]
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:
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.
If you have any questions or issues, please contact Assembla support at firstname.lastname@example.org.
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: