Archive for the ‘Uncategorized’ category

Q&A from “A First Look at Kando,” AccuRev’s Seamless Git Integration

February 3rd, 2012 by AccuRev

We held a “First Look at Kando” webinar on Tuesday to mark the launch of our back-end platform for security and compliance with Git. Unfortunately we weren’t able to answer all of the questions in the allotted time, so here are answers for some of the most commonly asked questions.

Q: Can a developer use Git without an AccuRev workspace?

A: Absolutely. With Kando, the developer does not require an AccuRev workspace. Kando uses a native git repository, so developers can use Git with no modifications – it works seamlessly with AccuRev on the backend. It’s all native Git-to-Git.

Q: Is the Git repository limited to a single AccuRev stream, or can it follow most or all of the AccuRev depot?

A: The Git repository is not limited to a single AccuRev stream, it is completely configurable. When you create a repository, by default, it’s going to ask you to map the master branch in that Git repository to a stream in AccuRev, but you can set up multiple mappings. You could map 100s of branches to streams if you wanted to.

Q: Let’s say I’m an integration manager for a project. Can I create a Git repo using Kando, Git clone it on my system, and let other users clone from me?

A: You can certainly use that model if that’s how you’re most comfortable, where you clone from the bare Git repository associated with AccuRev, and then other people can clone from you. There’s nothing to preclude that from happening because it’s normal Git-to-Git. Another possible solution would be to have all of your developers push and pull from the Kando repository, then you could merge those changes up to the QA or Master branch using AccuRev or Git if you prefer. Kando supports both models.

Q: What about integration with code review tools (like Gerrit).  We actually use Gerrit as the centralized control for our Git repositories

A: If you are connecting Git to anything, whether it be Gerrit, GitHub, an open source library, etc., everything will work. Because Kando is reliant on Git working natively, you can connect to Gerrit or any other tool that integrates with Git. You can push and pull from Gerrit and GitHub as normal. When you push to the remote that is associated with Kando, which is connected with AccuRev, those changes end up in AccuRev in the stream that you’ve mapped to the Git repository’s branches.

Q: How do you handle bugs in Kando itself? Is there support?

A: Kando is an officially supported AccuRev product. If there are defects in Kando, they’ll be handled through our support and services organization the same as they would with AccuRev. Kando is developed using an Agile development methodology, so as we get feedback on defects and enhancement requests, we will turn around fixes and enhancements as quickly as possible.

Still have questions? Ask below, visit www.accurev.com/kando for more information, or check out the Kando video.

Agile Training & Spring Training

April 26th, 2010 by JMartin

We recently produced a webinar here at AccuRev, co-sponsored by Rally Software, about the Top 10 Factors for a Successful Agile Implementation. Guest blogger JMartin, of Rally Software, enlightens us on our next factor.

Number 8 is all about Agile Education, or as I like to call it, Agile Spring Training.  After choosing our Pilot team, it only makes sense they next need Agile training and coaching.

Another season of baseball has started.  Baseball seems to have such a long slog of a season.  It’s hard on the fans, that’s for sure.  I suppose it might be hard on the players, too, eh?  And even so, every year, there is still Spring Training.  The teams gather in the warmer parts of the country to practice and scrimmage and practice and work out and evaluate and practice.  How much does the average player make?  Couldn’t the teams be getting a better return on their investment if all this extra time players were using to train and practice was put toward “real” games with full-paying customers and sponsorship back home?

Obviously, training is important.  Spring Training helps provide and refresh the underlying skills of the professional baseball player so that he can move beyond his talent and perform with his coworkers on the field.  Even the most expensive players train.  Really, a successful effort of any kind requires some level of training.  For the players on the field, it is important to train them together to give them a common feeling for each others’ behaviors and to focus their vision on the same goal and approach as provided by their manager.  In the same way, teams adopting Agile should be trained so that they have an understanding of the process and so that they share a common language to help them have or improve upon communication about what’s going on as they dive in.  By giving a team a common language and skill set to operate with, we eliminate the kinds of hiccups in execution that are caused by incompatible expectations and other breakdowns in communication, as well to keep the players from getting lost.

Agile Training provides common languages and a pattern set for teams to understand and follow.

Did I stretch the baseball metaphor in there enough?  If not, think about this: after Spring Training is over and the season begins, are the players just released onto the field and left to play games on their own?  No, they go through the season with a staff of coaches who monitor their performance and help them plan and improve both their off-field training regimens and their in-game strategy.  Baseball teams get help in another way, too:  at the end of the season, the teams that are on-track for the pennant race do something interesting to their teams.  They start looking around for seasoned players.  The seasoned players aren’t brought in so much for their skills in playing the game itself (we’re relying on the younger, faster kids to do the hard work!).  You’ll hear sportscasters talk about how player X was brought in to provide experience and stability to the team as it hits the turbulent times of post-season play.  They help mentor the younger players both about on-field strategy and about dealing with distractions.

Agile training and coaching works in a similar way.  Training provides common languages and a pattern set for teams to understand and follow.  A good training set will provide muscle memory for the basic mechanics of Agile.  And an environment geared toward allowing team members to get the technical training and in-fill they need helps the team be ready to succeed in the game.  It’s great for the tactics. But very successful teams also get the help of a coach.  An Agile coach can provide help at the strategic level, helping to plan the agile rollout and watching team behaviors to suggest areas for extra practice or additional training.  In addition, a good coach is someone who has real experience.  When a need for help arises in the team, the coach can pull from her well of experience to give the team not just a way to strategize their way around a rock but a little bit of the confidence from having gotten through those rocks before.

Somehow, I went from baseball to kayaking.  I’d better stop before I bring in some curling metaphors.  The point here is that a successful agile adoption requires the creation of a culture of learning and that learning must be provided at the tactical/basic mechanics level and at the strategic/vision-oriented level.

What’s a Manager to Do? Management’s Role in Scrum Organizations, Part III

March 15th, 2010 by lorne cooper

I love the concept of self-managing teams.  Everyone figures out what needs to be done, and does their best to make the greater organization successful.  Beautiful.  Reminds me of the Shaker Village, the Russian Artel, or the Israeli Kibbutz.  All of which are (largely) extinct today.

There are three structural problems that, like termites behind the wallpaper in a French Quarter house, cause these “worker’s paradises” to fail.  Our job, as managers of the Innovation Engine, are to sniff ‘em out, expose them, and exterminate them.

Problem #3: The Buck Starts Here.

For all the happy talk about mission, values, and meaningful work, the ultimate metrics for business are financial.  Our inability to grow, make profits, secure new investors, etc., will ultimately end our ability to accomplish our missions, support our values, or provide work to our employees and worse yet, ours bosses. That’s the bad news.

The good news is that we managers can use money (or their engineering equivalents, people) to accomplish great things.  Which things we choose to accomplish is largely up to us.

No, that doesn’t mean we want to create our own user stories, and reprioritize the backlog to meet the requirements communicated to us in our sleep by our deceased pet snake.  That’s the product owner’s job.

The Scrum process, like its Lean predecessors, is based on incremental improvement.  That’s great for two reasons: first the changes are small enough that we can get them done and see the results before the environment has changed, and second because they are small enough in scope that the individuals in development or product management can understand and control them.

We managers have to see the bigger picture, and that generally means determining the funding level for each of the initiatives we have.  Adding people to a team will eventually, not withstanding our bad management, increase its velocity.  Pulling people off will generally do the opposite (although not as quickly as you might think …….).

The optimization problem for the overall success of the organization involves lots of variables, but that’s really why they pay us the big bucks.  Is this group servicing a stable and productive customer, while this other group is struggling to overcome a mountain of technical debt?  Are competitors starting to emerge for what has been a stable area? Has this project achieved most of its goals? Is it time to determine what should be the next big initiative?

The purely business and marketing side of the equation is usually an area of influence, not control, for the development manager.  But the assignment of resources to projects is the execution of that strategy, and requires management comprehension and “buy-in.” For those of you uncertain, the term “buy-in” refers to agreeing to do something you’d really rather not do at the risk of losing your job.  It’s been around a long time, but has flourished in the recession.

On the technical side, there are important funding issues to consider.  One of the biggest is the effect of architecture on the overall success of projects.  Studies have demonstrated that one of the biggest factors in ROI for IT initiatives is the quality of the underlying architecture.  Should you add features to your Windows XP app, re-write it to run on an i-Phone, or re-write it to run within your CRM system?  Big questions with lots of impact both in the short term or long term.

Conclusions

Senior engineering management is a tough job with many tasks and responsibilities, too numerous to list here, but including team dynamics, people management, strategic funding decisions, and golf at expensive resorts.  Middle management has similar responsibilities, without the golf.

Great organizations are rarely the product of good luck.  Great leadership recruits the right people, puts them in the right roles, identifies problems and fixes them, and looks ahead at trends to make sure resources are assigned to the right places.

In Scrum, this doesn’t require a lot of managers, but does require of lot from managers.  Empowering managers to act, and ensuring that they do, is critical to the long-term success of your Agile organization.