The Brandeis GPS blog

Insights on online learning, tips for finding balance, and news and updates from Brandeis GPS

Tag: scrum

SPOTLIGHT ON JOBS: New Dimensions in Technology Recruiting

spotlight-CHANGED-300x200SPOTLIGHT ON JOBS

Members of the Brandeis GPS Community may submit job postings from within their industries to advertise exclusively to our community. This is a great way to further connect and seek out opportunities as they come up. If you are interested in posting an opportunity, please complete the following form found here.

Where: This position is with a confidential company in Cambridge, MA. Applicants interested in the position will work with the New Dimensions in Technology Recruiting Agency.

New Dimensions in Technology (NDT) continues to be on the forefront of change. Our experienced Recruiting Team has seen industry trends come and go. NDT Recruiters have developed keen insight into companies that are most likely to grow and prosper. NDT also offers a proven track record of successful matching of candidates with client companies by understanding our candidates career goals and knowing the needs of our client companies and their corporate cultures. We have partnered with start-up companies to staff and grow their businesses into FORTUNE 500 companies; we have assisted our mid-size and large client companies in recruiting the most sought after superstars. No matter what the global economic conditions, NDT consistently delivers value to both new and long-time client companies and candidates.

Position: Head of Engineering Operations

The engineering team is looking for a results-oriented person to establish our Engineering Operations capability. The ideal candidate will thrive in a fast-paced environment, have strong project management and organizational skills, be experienced with modern software development process and tracking tools including data analysis and reporting functions, be familiar with agile software development processes, and strong communications and people skills.  The Head of Engineering Operations reports to the SVP Engineering, and is a project management and reporting service resource to the individual development teams and the engineering department as a whole.

Required Skills and Experience:

  • 5+ years of industry experience as software project manager.
  • Experience with Agile Methods (Scrum), especially as it relates to project-level information and reporting.
  • Strong organizational skills and comfort with detailed information, including financial, technical tasks and workstreams, and deliverables/action items.
  • Self-motivated, driven, and results-oriented.
  • Strong verbal and written communication skills.
  • BS or BA in Management, Business, Computer Science or equivalent. 

Great to have Skills and Experience:

  • High-tech software company experience, especially databases.
  • Experience with specific development environment tools experience:
    • JIRA
    • Confluence (Wiki)
    • Bamboo

Click here to view further details on this opportunity!

To receive full consideration for this position, candidates are asked to submit a Resume/CV and Cover Letter through the recruiting agency’s online portal here.

Please make sure to reference seeing these positions through the Brandeis GPS job spotlight post.

Not subscribed to our blog?

Click here to subscribe!

Footerindesign

Design Your Agile Project, Part 1

by: Johanna Rothman

Find the original post here: http://www.jrothman.com/blog/mpd/2014/03/design-your-agile-project-part-1-2.html

The more I see teams transition to agile, the more I am convinced that each team is unique. Each project is unique. Each organizational context is unique. Why would you take an off-the-shelf solution that does not fit your context? (I wrote Manage It! because I believe in a context-driven approach to project management in general.)

One of the nice things about Scrum is the inspect-and-adapt approach to it. Unfortunately, most people do not marry the XP engineering practices with Scrum, which means they don’t understand why their transition to agile fails. In fact, they think that Scrum alone,without the engineering practices, is agile. How many times do you hear “Scrum/Agile”? (I hear it too many times. Way too many.)

I like kanban, because you can see where the work is. “We have a lot of features in process.” Or, “Our testers never get to done.” (I hate when I hear that. Hate it! That’s an example of people not working as a cross-functional team to get to done. Makes me nuts. But that’s a symptom, not a cause.) A kanban board often provides more data than a Scrum board does.

Can there be guidelines for people transitioning to agile? Or guidelines for projects in a program? There can be principles. Let’s explore them.

The first one is to start by knowing how your product releases, starting with the end in mind. I’m a fan of continuous delivery of code into the code base. Can you deliver your product that way? Maybe.

How Does Your Product Release?

I wish there were just two kinds of products: those that released continuously, as in Software as a Service, and those with hardware, that released infrequently. The infrequent releases release that way because of the cost to release. But, there’s a continuum of release frequency:

Potential Release Frequency

How expensive is it to release your product? The expense of release will change your business decision about when to release your product.

You want to separate the business decision of releasing your product from making your software releasable.

That is, the more to the left of the continuum you are, the more you can marry your releases to your iterations or your features, if you want. Your project portfolio decisions are easier to make, and they can occur as often as you want, as long as you get to done, every feature or iteration.

The more to the right of the continuum you are, the more you need to separate the business decision of releasing from finishing features or iterations. The more to the right of the continuum, the more important it is to be able to get to done on a regular basis, so you can make good project portfolio decisions. Why? Because you often have money tied up in long-lead item expenses. You have to make decisions early for committing to hardware or Non Recurring Engineering expenses.

How Complex is Your Product?

Let’s look at the Cynefin model to see if it has suggestions for how we should think about our projects:

CynefinI’ll talk more about you might want to use the Cynefin model to analyze your project or program in a later post. Sorry, it’s a system, and I can’t do it all justice in one post.

In the meantime, take a look at the Cynefin model, and see where you think you might fall in the model.

Do you have one collocated cross-functional team who wants to transition to agile? You are in the “known knowns” situation for agile. As for your product, you are likely in the “known unknowns” situation. Are you willing to use the engineering practices and work in one- or two-week iterations? Almost anything in the agile or lean community will work for you.

As soon as you have more than one or two teams, or you have geographically distributed teams, or you are on the right hand side of the “Potential for Release Frequency” chart above, do you see how you are no longer in the “Complicated” or “Obvious” side of the Cynefin model? You have too many unknowns.

Where Are We Now?

Here are my principles:

  1. Separate the business decision for product release from the software being releasable all the time. Whatever you have for a product, you want the software to be releasable.
  2. Understand what kind of a product you have. The closer you are to the right side of the product release frequency, the more you need a program, and the more you need a kanban to see where everything is in your organization, so you can choose to do something about them.
  3. Make sure your batch size is as small as you can make it, program or project. The smaller your features, the more you will see your throughput. The shorter your iteration, the more feedback you will obtain from your product owner and “the business.” You want the feedback so you can learn, and so your management can manage the project portfolio.
  4. Use the engineering practices. I cannot emphasize this enough. If you do not keep your stories small so that you can develop automated unit tests, automated system tests, use continuous integration, swarm around stories or pair, and use the XP practices in general, you will not have the safety net that agile provides you to practice at a sustainable pace. You will start wondering why you are always breathless, putting in overtime, never able to do what you want to do.

If you have technical debt, start to pay it down a little at a time, as you implement features. You didn’t accumulate it all at once. Pay it off a little at a time. Or, decide that you need a project to prevent the cost of delay for release. If you are a technical team, you have a choice to be professional. No one is asking you to estimate without providing your own safety net. Do not do so.

This post is for the easier transitions, the people who want to transition, the people who are collocated, the people who have more knowns than unknowns. The next post is for the people who have fewer knowns. Stay tuned.

Johanna Rothman

Protected by Akismet
Blog with WordPress

Welcome Guest | Login (Brandeis Members Only)