Hey you! Are you working through some issues but don’t have time for the therapist’s couch? When you sit down and start working with the merge tool in GitKraken, all your internal struggles will disappear. No hypnosis or guided imagery needed.
Because the fact of the matter is conflicts are pretty common—in coding and in real life. And sometimes you need a referee, a parent or a therapist. Enter GitKraken’s merge conflict tool. It’s like having all of those three people in one.Here’s the Deal
According to Jose Garcia, Developer at Axosoft, “When you try to merge files or branches together you’ll occasionally get conflicts,” which in the past would force you to get out of your Git client, open another app, etc. Essentially, you have to take a bunch of extra steps.
Well, not when you use GitKraken! “The GitKraken merge conflict tool lets the user combine code the way he or she wants,” explains Garcia.
“Most Git clients ask you if you want to install another app. GitKraken will ask you, but also provides a way to resolve the conflict right in the app.”
According to Garcia, “One of the main goals of GitKraken is to keep users in the app so they don’t have to leave it to do things they should be able to do in GitKraken.” He goes on to explain that in order to do this, redesigning the UI was paramount.
“We had to make a custom area,” he reports. “There are three small windows that show you three different versions of the same file; so if you scroll through one, you want the other two to do so as well,” he explains. “We added that synchronization functionality.”The merge conflict tool performs in-app. Using the Merge Conflict Tool
It’s pretty straightforward, really. When you have a merge conflict, simply click on the conflicted file. Instead of opening the regular diff view you’re familiar with, it will open a specialized view for helping you resolve merge conflicts without having to leave the app.
This view has three different sections:
- The two side-by-side sections on the top half show you the different versions of the file you are trying to merge.
- The third section on the bottom half shows the output.
To select which lines you want to take, you can click on any individual highlighted line to add it to the output. You can also use the checkbox next to each conflict section to add the entire chunk to your output.
You can also just decide to take an entire side with the “Take All” button. The arrow buttons help you quickly navigate between the different conflicts in the file.
When you are happy with your selections, click on “Save and Mark Resolved” to save your file and stage it.
Check out the GitKraken release notes for more details about the merge conflict tool; it’s just another step toward making GitKraken 100% standalone!
Cross-functional teams are a set of people (and sufficient tools) that have all the abilities to produce a complete increment of work. Cross-functional teams can self-organize to figure out the best way to complete that work.
I call great cross-functional teams gravy because I grew up in the south and well, we put gravy on everything. An adaptable team can do a variety of things well. So Just like gravy you can pour them on mashed potatoes, but also the fried chicken too! It doesn’t mean we have cogs, but it does mean that they can adapt over time. They help each other overcome obstacles and they do it through learning and being intentional about where they are improving.
When turning a traditional team into a Scrum team, you get a bunch of people that have very specific roles. BA’s, QA automation, QA testers, UX engineers, Service Engineers, etc.
Waterfall methodologies, as they are implemented in most organizations, incent a person to stay in their specific lane. BA’s do requirements, QA manual testers manually test, and so on. There are a high number of specialists that go deep into their craft.
When you turn those same people into a Scrum team, the incentives change. The people on the team are incentivized to be cross-functional so that roadblocks and bottlenecks are cleared rapidly.
Here’s how I start off new teams when they begin Scrum.
First, we do need some specialists. Not everyone will automate everything, not everyone will know the corporate security protocols. This needs to be acknowledged. It’s not about going to an extreme edge where everyone can do everyone else’s jobs.
Second, it is about bottlenecks. During the task breakdown section of sprint planning, I horizontally map the workflow of the team to the stories they are trying to complete using sticky notes. I find it best to walk backwards from production. How do you promote to production? Did anyone do it for you? Are they on this team or is that a dependency? What about regression? Etc. I do this all the way back to the origin of the work for a new Scrum team.
Next, I ask the team to put their names under each state for what they could possibly do. I will ask them to elaborate on the ability they need to complete the task, (i.e. Java).
Once that is done, we can identify bottlenecks. A certain person may be the only person that can perform a task. If they are out, the team has to wait. That person needs more slack in their personal system so that they are never causing the team to wait.
In order to overcome this, the team can decide if the bottleneck is important enough to cause them to generalize. They may pick one or two members to learn that ability so that the team can remain adaptable in the face of change. The team needs to consider what to change instead of going all in and trying to become generalists on everything. This method causes the visualization of bottlenecks, skill sets, and will unbury hidden treasure (skills) in the team’s system. The team can then prioritize and tackle the solutions that will make them faster with the same or higher level of quality and really internalize the fact that they are a team. From there, it’s all gravy.
I spoke with a Scrum Master recently who told me his team had nearly doubled their velocity in only two months. Rather than be happy about this, though, he was concerned.
He knew the team had not suddenly become twice as productive. In fact, he doubted they'd actually sped up at all. Yet their velocity showed they had.
The cause of this sudden and dramatic increase was story point inflation. Or, more generally, estimate inflation, because the problem can happen with estimating units other than just story points.
Estimate inflation is when the estimate assigned to a product backlog item (usually a user story) increases over time. For example, today the team estimates something will take five points but previously they would have called it three points.Why Does Estimate Inflation Happen?
There are a few possible causes of estimate inflation. One of the most common, though, is excessive pressure on the team to improve or deliver more points per sprint. This often comes from bosses or possibly stakeholders outside the team who are pushing the team.
Velocity becomes a really tempting (but bad) metric in these cases and teams are pushed to demonstrate that they’re going faster by increasing velocity.
When a team is under pressure to increase velocity, team members will often start to round estimates up during story point estimate meetings (often done with Planning Poker). For example, consider a team that is debating whether a particular story is three or five points. They’re having a legitimate debate about this.
At some time during that discussion, one or more people will remember the team is under pressure to increase velocity. And some might shift in favor of calling the story five points instead of three.
I want to be clear this isn’t lying. It’s not blatant padding. The team was truly debating three versus five. And when someone remembers the team is under pressure, that person switches to favor five.
And so that story is called a five.
Now consider another story being estimated perhaps a week or two later. In considering the new story, someone compares it to the five-point story and thinks, “Well, this new one is a little bigger than that five,” and proceeds to estimate it as perhaps an eight.
And this is how estimate inflation happens.How to Prevent Estimate Inflation
I’ve found the best way to prevent estimate inflation from occurring is to always compare the item being estimated against two (or more) previously estimated product backlog items. In my “Agile Estimating and Planning” book, I referred to this as triangulation, borrowing the old nautical term for fixing a ship’s location.
So, when a team thinks about estimating a story as five points, they would first compare that story to two other stories--ideally one smaller and one larger. In deciding if a story should be estimated as five points, they would compare the story to a three-point story and think, Will the effort to do this new story be a little more than this three-pointer?
They would next compare that story against an eight- or 13-point story. And they’d want to see if the story felt appropriately sized as five in comparison to one of those. These comparisons are shown in Figure 1.
Triangulating a 5-point story by comparing it with 3-point and 13-point stories.
When an item being estimated is compared to two or more previously estimated items, it helps ensure the internal consistency of the estimates.
Ideally we’d love to consider each estimate in comparison to all previous estimates. But that would be way too much work. Triangulating a story by comparing it to two others is generally sufficient.
If we think about the stories as nodes in a graph, triangulating can be visualized by drawing lines between each of the nodes the team explicitly compared while estimating. This can be seen in Figure 2.
Each story, A-F, has been compared with two or three other stories.
Here we see that product backlog items A and B have been compared to three other items each. Backlog items C through F have each been compared twice.Triangulating Stops Estimate Inflation
Triangulating prevents estimate inflation because the use of two comparisons helps point out when estimates are beginning to inflate.
To see this, consider the team that is trying to decide between estimating a story as either three or five. Remembering they are under pressure to increase velocity, they decide to call it a five. And it may legitimately seem just a bit bigger than some other three-point stories.
But, when the team triangulates that story against another five or an eight, they’ll most likely realize that the story is not really a five.There’s One More Good Way to Prevent Estimate Inflation
There’s at least one more very good way to prevent estimate inflation. But, since this post is already long, I’ll save that for the weekly tip I share each Thursday by email. If you’re not already subscribed, consider signing up now if you’re interested in learning more.What Do You Think?
Has estimate inflation been a problem on your team? How do you handle it? Please share your thoughts in the comments below.
Agile teams use product backlogs to manage their requirements. Product owners prioritize the user stories. To enable delivering products with sufficient quality agile teams need to have user stories that are ready at the start of an iteration. Continue reading →
I gave a talk about The Road to Agility at the 7th Agile Eastern Europe (#AgileEE) conference in Kiev, Ukraine. This was the second time that I presented at AgileEE, I was invited back by the organizers after giving a talk on Sustainable Improvement through Agile Retrospectives in 2015. Continue reading →
Targetprocess v.3.8.6: Batch Delete from context menu, Quick Add Relations in Lists and Boards, Focus on selected cards, Import/Export for Team States and Teams
We are on our way to making batch actions easier to perform. To start, we've enabled batch delete using a context menu for all view modes where a group of cards can be selected (Board view, Timeline view, One-by-one view and a clipboard).
From now on, it will take less clicks to add relations to your entities. Quick Add is now available from Relations Lists and Board views.
Before v3.8.6, you could only focus on whole lanes. Now, you can focus in on cards as well. Select cards and (or) lanes you want bring into focus, and then press the Focus button at the top of the view.
Your data can now be exported to a CSV file with all Teams and Team State fields intact. Just build a view with entities you are interested in and click the ‘Export’ button from the ‘Actions’ menu to download a CSV file. You can also set these fields from a CSV file if you map the Teams, Team State, and Team Iteration fields before importing.Date units for project
Several new units have been added for cards: Planned Start, Planned Finish, Forecasted Finish, and Anticipated Finish. Go to the Customize Cards tab in a view's settings to add these units to your cards.
Inline Editing of Percent Participating and Start/End Date in the Allocations list is now available! Hover the mouse over a unit and edit the value with one click. The option is available on User/Team/Project Detailed views.
- Fixed copying an entity with all its custom fields values
- Fixed Rich Text Custom Field display in a Print view
- ‘Remove Relation' button is replaced with the ‘Unlink’ button
- Improved Global Quick Add Performance
- Fixed attachment display for users that are not the attachment's owner
- Fixed highlighting of cards in a clipboard
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
I have a problem. Despite teaching people and organizations how to organize their work effectively, how to prioritize, about the evils of multi-tasking and the importance of sustainable pace, I have never been able to get my own to-dos under control. By extension, my life has never really been under control either. So I often work late into the night, almost every night, and on the weekends as well.
I have experimented with the Pomodoro (I could never get myself to stop working after 25 minutes. I want something done before I can put it down) and Personal Kanban (post-its with waiting-working-done around the screen of my notebook (the problem wan't the WIP but the length of the backlog). The results of my attempts was always the same: I worked very hard, getting things done one after the other, but my work schedule always extended into the night and over the weekend.
An experiment with timeboxing tasks/goalsTwo weeks ago, a read an article on linked in, Critical Things Ridiculously Successful People Do Every Day, by Travis Bradberry. His first recommendation: "[F]ocus on minutes, not hours." Enter your program in your agenda. A light went on. If I am going to do something, the first question I must answer is when am I going to do it? Then I block the time for that activity. What happens if I don't have time for it? Either postpone it, don't do it, or cancel something else.
So I decided to try an experiment. For one week, I would schedule every major activity I needed to accomplish. From Sprint Planing for the SBC website, to quotes I needed to send customers, a talk I needed to prepare, to packing for my trip to the Scrum Gathering. Everything went into my calendar. Looking back on it today, I see that I had 30 individual items over five days. Only once did I schedule work into the evening.
What happened? The good news: Friday morning, when it came time to leave, my wife said, "it's time." I said, "OK," put my suitcase in the car, and off we went. On the way, she said to me, "I have never seen you so organized and ready for departure before a trip like this!". (And I hadn't even told her about my experiment!). I accomplished every major goal I set for myself that week (except one). And I had time to watch 4 hours of amateur Star Trek videos on you tube without feeling guilty! Wow.
The bad news. My estimates suck. It starts with the assumption that 30 minutes every morning is enough to deal with routine emails. So I had to deal with that.
Having a schedule in my calendar, and new goal starting half an hour from now, has proven to be an interesting attractor. It reminds me to focus my attention on the right thing. I can look at my calendar and see what I should be doing.
If I get to the end one time box, and the goal has not been achieved, I have to ask myself the questions, what do I do now? Do I keep working on my current goal? Or do I schedule the remaining parts for later? Or do I cancel or postpone the next goal?
Depending on the situation, I have already done all of these. Remember, I said there was one major goal I did not accomplish? Well, I got to the time when I was supposed to start it, but I was nowhere near finished the previous goal. I evaluated the importance of the two goals and decided that it was more important to finish the goal I that I was working on. So I finished it and dropped the other one (urgent but not important). So timeboxing individual goals enables me to prioritize and ensure that the most important things get done. After a week of this, I was pretty happy with my results.
What does this have to do with Scrum? For me, Scrum consists of 6 essential patterns:
- Inspect and Adapt at regular intervals
- Produce something that might be valuable at least once per interval
- Management leads and supports, and knows when to stay out of the way.
- The whole team solves the problem
- One voice speaks for the customer/maximizes the value of the work done
- A coach helps everybody achieve higher performance.
Inspect and Adapt at regular intervals.
Produce something that might be valuable at least once per intervalFirst, I have stopped calling it task planning. I allocate time to achieve a goal, not perform a task. So I keep focus on the fact that my work should produce value. At the end of a time box, I hope that the goal will have been achieved. If not, that is the moment to Inspect and Adapt. I allocate time in Pomodoros (units of 30 minutes, including a 5 minute break). Nothing takes less than one Pomodoro, and I never block more than 4 consecutive pomodori for a goal. Often I achieve my goal. Sometimes I don't. That is when inspect and adapt is really helpful!
The whole team solves the problemThis one is actually pretty easy. I am the whole team. Management leads and supports, and knows when to stay out of the way.I don't think this is really relevant in my context. I am basically a one person company. Not much of a management layer. :-)One voice speaks for the customer/maximizes the value of the work doneThis one is a bit tougher. Can I effectively be my own product owner? I think so, but I am going to keep an eye on this one. I started to set longer term goals by allocating time further in the future to achieve them. Aside from managing time I am not yet managing a formal backlog. A coach helps everybody achieve higher performanceIs it possible to be my own Scrum Master? I don't think so. An essential aspect of being a Scrum Master a Scrum Master is the independent perspective. On the one hand, I don't feel like I have systematic impediments. On the other, how do I know that I am focussing on the right goals? How do I know that I am working effectively? I think there needs to be second person involved.Next experimentsThis week, I will continue with the approach. I have also asked my wife to play the role of Scrum Master and I'd like to add a Sprint Planning/Review and maybe even a retrospective. Hmm, that means scheduling time for it...My Personal Scrum, v0.1How am I doing Scrum for myself?
- When I decide I want to achieve a particular goal, I also decide when I will work on it, and block that time in my agenda
- If I have no time to work on a new goal, I have to either postpone the goal, reject the goal, or reschedule or renounce another goal
- I strive to work on / that which is planned at any given time
- I know my estimates suck, so I leave slack in my agenda and forgive myself if things don't get finished when I hoped/expected.
- My agenda serves me, not the other way around. So if reality is different than plan, I adjust the plan to reflect reality.
Many of you will already be familiar with the Galactic Empire (spoiler alert: we’re the ones ruling the galaxy through fear and intimidation). It’s really great to have this opportunity to share some of my experiences in the challenging, but rewarding field of galactic domination and demonstrations of hitherto inconceivable power and destruction.Approaching Agile Like a Master
Our releases are pretty mammoth. Like 120km mammoth in the case of our Death Star, and it’s the Death Star I’d like to discuss with you in this article. It almost never got completed and in fact could have been DESTROYED had we not discovered – and repaired – a small but nonetheless major flaw in our design. More on that later.
You may think that building a Death Star is as simple as welding together a few million panels of metal, wiring up some electrics, adding a few light fixtures and firing up the wireless router. Let me tell you right now: Death Stars are a logistical nightmare. They are pretty much financial suicide and include countless concerns and protocols, not to mention the amount of hardware and software development required. Also, it’s worth mentioning (and I’ve said this before) that ____tech terror.
Most of these needs have to be outsourced to contractors across the galaxy, adding even more complexity to the logistics of the project. Several times I almost lost my mind trying to keep track of everything. Folks, I’m not exaggerating. Planning a Death Star absolutely sucks.
An omnipresent threatening force is a useful methodology, but myself and my master, Emperor Palpatine, soon came to the realization that a more pragmatic, controlled and proactive approach to our project management was needed to pull off such monumental and complex ventures and have everyone play ball in a timely manner.
We of course adopted an Agile approach. But Agile is not in and of itself the solution to complicated projects – it needs to be implemented well.
Thank the Force we discovered Axosoft to implement our Agile workflow. Here are just a few ways in which certain Axosoft features helped us see some exciting (and some less so) aspects of Death Star planning through to completion:
We needed to have the ability to plan our releases, both as a way of planning projects within the overall scope of the Galactic Empire’s continuing dominance of the galaxy, but also within each project.
We were able to plan with a forward-thinking methodology (we might, implausible as it may seem, decide to build another Death Star, for example) and also split up our Death Star progress into sprints to ensure milestones were clearly defined and completed on time.
Many subsequent tasks were dependent on completion of our defense systems, and so our shield and defensive firepower planning and construction formed our first sprint, with subsequent sprints being populated with items contingent on that security being in place (offensive weaponry and phase 2 of actual construction are two obvious examples).
Other items could run concurrently across multiple sprints, such as Human Resources policies, onboarding processes for certain staff members (but not others), etc.
[image of planning release sidebar]
The overview of our backlogs was essential for us to be able to glance at outstanding and completed items, see what priorities needed addressing, and filter down into a narrower selection of items. Using workspace tabs, we were able to filter items by designation, by sprint, and all sorts of other ways, and then save these views in convenient tabs at the top of the screen.
Within the DS-1 version (essentially our project), we added sprints to understand where in the overall project certain milestones would occur and what needed to be completed to meet them on time. For example, we were able to work out precisely at which stage in development the Death Star’s weapons and shields could be fully operational, even before overall completion.
Using Axosoft’s Release Planner, we were able to quickly drag and drop items to assign them to team members. Once we had assigned tasks, we could, at a glance, see how many hours each team member had available, and could see whether members were overstretched or underutilized.
For example, as the development of our laser was completed ahead of schedule, we were able to reassign several scientists and engineers to the more menial task of uniform design and stitching, which was behind schedule. We were able to see at a glance that our workforce in this area would have been way overstretched, and so we made a polite request that others become team players.
After all, showing of the destructive power of a planetary deathray hardly looks impressive when conducted in the standard issue Empire polo shirts and khakis.
Overall, these features allowed us to prioritize certain tasks so as not to hold up subsequent releases.
[image of backlog list]
[maybe mention Kanban view here too]
Burndowns and Dashboard
Work progressed and we amassed more data as workers entered in work logs. This allowed us to compare projected work hours with actual hours, and identify where we were underestimating the time that items would take.
We used the snazzy burndown chart and dashboard to analyze this data and predict our completion dates. From there, we could make adjustments as necessary to get back on time.
(As an aside, this has become far easier to enforce now that the Death Star can destroy your home planet if you underperform. Nothing like the obliteration of your entire world as motivation to try just a little harder, is there?)
This was a big one, especially for the higher-ranked members of the team. Previous face-to-face standups had the unfortunate tendency to create situations where emotions were running high. Individuals would inevitably overrun or deviate from the discussion at hand, and this would lead to raised voices, sarcasm, and eventually force chokeholds from yours truly. In standup mode, we are kept to task, and things are, well, less disturbing.
Need to finish this entry but have some ideas. The example Wiki I’ve made drafts an HR form whose final version will be available to download (here it is — download, don’t view in drive, as it’s garbled in drive)
[image of projected Death Star plans]
Literally. Using Axosoft helped us to better share updates, understand and anticipate the progress of every team, and adjust quickly to accommodate any unexpected changes in scope.
We were able to see a timeline of comments and progress, and re-assign tasks as necessary to have a clear picture of who was responsible for what at every stage of the item’s progress. This was especially important re a small issue that turned out to be pivotal in our balance of power in the galaxy.
[changes in scope come from burndown charts]
A small vulnerability in our exhaust port seemed minor at first, but just the right shot could have DESTROYED the Death Star! LOL, can you imagine? Axosoft allowed us to track our defense items much more robustly, and we were able to discuss issues and ensure no rash decisions were made (or ignored) without the oversight of other team members. We were able to act swiftly and with a clear chain of command to implement fixes.
Long story short – the flexibility that Axosoft afforded the Galactic Empire during the Death Star’s construction meant that the old plans stolen by the Rebel Alliance were not quite – ahem – accurate anymore.
We had completed ahead of schedule, but had also managed to squish a fair few bugs and design flaws that might otherwise have slipped through the cracks. Flash forward to the Battle of Yavin, the Rebel Alliance thinks we’re vulnerable – SURPRISE! – we’re not! We win the battle, crush the Rebellion and the Death Star shines on as a symbol of fear and tyranny throughout the galaxy. Pretty certain that’s how it went down.
About Darth Vader
Lord Vader began his career as a young pod racer before becoming a Jedi knight, the most powerful Jedi knight. It wasn’t long before his talents were noticed by a soon-to-be-Emperor Palpatine and before long, Vader was using the power of the Dark Side and had become more powerful than you could possibly imagine. He now rules the galaxy with Emperor Palpatine.
His hobbies include force chokeholding subordinates, spending time alone in a special capsule all of his own, reading, dogs and frequently guest writing for various blogs across the galaxy. His favorite bands are U2 and Coldplay.
Detailed task view, with comments thread, segways into the exhaust port one. Also show PDF export because the emperor likes to have everything printed off and bound.
Have you ever lost your glasses or forgotten your contacts? (If you have perfect vision, congrats to you, but please stay with me). In your glassesless search around your house, did you grope for a lamp only to find it was your cat or last night’s Chinese takeout? Regardless, you know how annoying it is to not be able to search successfully for specific items.
You also know the feeling of finding your glasses, seeing clearly, and going back to being a productive human. This is what GitKraken’s new Fuzzy Finder does for you. It helps you search and find what you need super fast (without mistakenly handling old Chinese food).In Search Of
So back in the day when there wasn’t online dating, there were newspaper ads that lonely singles posted which typically started with the letters ISO—standing for In Search Of.
Singles would describe their perfect person and include a phone number. If you embodied that description and you happened to be single and you happened to be reading the ad, and you happened to feel like calling a strange number, you just might meet and fall in love.
There’s a lot of chance at play there. Luckily, technology has evolved, dating apps eventually appeared and now it’s easier to find what you’re looking for. Although our Fuzzy Finder won’t get you a date, you can find what you want within about 2-3 keystrokes.In order to use Fuzzy Finder:
- Hit cmd + p (Mac); ctrl + p (Windows and Linux)
- See the empty input at the top of the screen? Cool. Start typing the action you want to take (open repo, checkout, or history), or just a repo, branch, or file name. GitKraken will list suggested actions and items, even with incomplete words.
- Identify what you’re looking for and choose it.
- Congrats. You just saved yourself a bunch of time. Continue with life as you were.
According to Justin Roberts, UI/UX Lead for GitKraken at Axosoft, “You can start typing what you want to do and GitKraken will intelligently give you a list of options for what you can do. For example, if you start typing “O” GitKraken knows you probably want to open a repo.”
He continues, “It will show a list of your repos prefixed with “Open Repo:” from there you can either arrow down to the repo you are looking for or keep typing to refine your search down to one specific option”The Fuzzy Finder in action
As you probably know, many modern applications use this technique for searching. But the big deal for GitKraken users is it speeds up everything you do right in the application.
“This is especially helpful for users who have tons of repos,” says Roberts. “For users who work on a lot of different projects it gets tedious to always go back to the Open menu, scroll through the list of repos, find the one you want to open and switch back and forth. Now you don’t have to.”The Future is Fuzzy (but Clear)
So, now you know that you can search in-app and quickly find a command, but did you know that GitKraken is the only Git client with this feature? Yep, we’re pretty proud! Just remember cmd/ctrl + p. P—for “Procure” not “Print” (because what are you printing anyway? It’s 2016.)
“Now that we have this functionality we can add things to it,” explains Roberts. “We can continue to expand as we find places to optimize workflow. So if we find out that users are always doing one specific action repeatedly and going through the UI takes a little bit more time, we can make that task a little more accessible. We’re excited by the possibilities this will provide GitKraken users to become more productive users of Git.”
In Search Of saving time with the hottest Git client on the market? Check out GitKraken. You just may find the love of your life.
Lisette Sutherland posted a podcast we recorded about geographically distributed agile teams. See Organize Your Distributed Team over on the CollaborationSuperpowers site.
We covered how you can think about your geographically distributed agile team:
- Why you want a distributed agile team (yes, there are some great reasons)
- How you might organize your team.
Here are the articles I mentioned:
I wrote about the timezone bubble chart in Managing Timezones in Geographically Distributed Agile Teams
Here are three posts about Geographically Distributed Teams Have Choices for Lifecycles about options for how you might do agile with a geographically distributed agile team.
I even had a chance to rant about management. We had a blast, as you can tell. Hope you enjoy it.
This week at VersionOne we had the opportunity to celebrate our CTO Ian Culling for having a birthday. He won’t tell us how old he is, so I guess that means he’s over 20? If you get the chance to meet him you might think he’s in his 20’s!
The man is a big part of the culture here at VersionOne. He makes things fun in addition to being smart as hell and doing a bang up job as the CTO. Walk into the development area and you are sure to find traces of Ian’s shenanigans, Dumb & Dumber orange suit, a plethora of nerf guns, Oculus rift, OneWheel, and more recently a Razor drift cart.
He’s also known for showing up at events in “special” attire. It’s a thing we that we’ve come to expect from him, but there’s always an element of surprise to it. So in honor of his birthday, we thought we would egg him on for an upcoming golf event that we have going on.
Below is the email that went out from Holly Reynolds, an interaction designer on the product development team.
In case you didn’t know…. it’s Ian’s birthday today…
We all know how much Ian loves to dress up and as much as he probably would like to come to work in his actual birthday suit, clothing is not optional here at VersionOne.
Stars pass and we honor them by celebrating their life after they are gone, but that seems like such a waste. Ian’s not dead, but he is getting older. Each of these remind me of him in a special way. I’m pretty sure if you pick your favorite, we just might get to see this guy show up at the upcoming golf outing on May 16th (don’t forget to sign up…you’re welcome Michelle).
Reply to me with your vote by 5 pm today or add your own suggestion for the birthday guy if you please.
The results will be compiled and shared later.
Creator, eccentric, minus the weird hair.
The Artist Formerly Known as Ian
Calm, cool and….collected;
Purple pants are not above this man
Rowdy Roddy Culling
“I came here to chew bubble gum and kick ass.
And I’m all out of bubble gum.”
Comment on this post and vote for your favorite or make a suggestion of your own. We’ll share the results in a couple weeks!
The post How We Celebrated Our CTO’s Birthday and How You Can, Too appeared first on The Agile Management Blog.
It's the end of an era. After nearly 10 years of updates and lessons-learned, we’ll be removing Targetprocess v.2 following next month’s build. As we’ve explained in earlier posts, we’re doing this to help accelerate our development speed and make important improvements to Targetprocess v.3.
Most of our users are already on Targetprocess 3 and won't notice any difference. For those of you still using Targetprocess 2, this change means you’ll no longer have access to old lists, dashboards, or the Targetprocess 2 interface. Time sheets and custom reports will be preserved and migrated to Targetprocess 3.
If you need help transitioning to Targetprocess v.3 and training users, please do not hesitate to schedule a “Migration to Targetprocess 3” workshop.
Our last Targetprocess 2-supported build will be released in May 2016. All updates after this will not be compatible with v.2. If you absolutely don’t want to lose access to Targetprocess 2, let us know via email@example.com. We don’t recommend this option, but it’s your choice and we’ll take steps to help you keep your access to v.2. In this case:
For On-Demand accounts: We’ll move your account to a separate environment where you can continue working off of Targetprocess 2, but will no longer receive updates or new features.
For On-Site accounts: You won’t be able to upgrade your Targetprocess instance with any build released after May 2016. You can keep using Targetprocess 2, but with no new features or updates.
We’ve had some great times with Targetprocess 2, and we’ll always look back at it fondly. If you want to read the whole story behind the product, take a look at our company chronicles (2004-2014).
Let us know if you have any questions or concerns about this change. If you have any fond memories of v.2, we’d love to hear them in the comments. Now, it’s time for us to move on and look ahead to the future of Targetprocess. We hope to see fans of Targetprocess 2 there as well.