The Brandeis GPS blog

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

Tag: program management

Faces of GPS: Kevan Kivlan

Kevin Kivlan - Faces of Brandeis GPS Online Education - Brandeis GPS Blog

Meet Kevan Kivlan, MS, who serves as a Director for the US General Services Administration in New England. Kevan is responsible for the overall regional stakeholder program management where he oversees a team who provides program, project and acquisition advice to federal, state and local governments. In 2010, Kevan received an M.S. in Project and Program Management from Brandeis University after completing his undergraduate studies at Assumption College in Worcester, MA in 2002.

Continue reading

Creating an Environment of Leadership

by: Johanna Rothman

Find the original post here.

I bet you have some problems that have been problems for a while. Or, you want to influence other people to change. You need an environment of leadership, because you can’t do it alone.

Here are three tips to creating an environment where everyone can lead:

Tip #1: Share the problem.

When I work with technical and managerial leaders, I find that they have this idea that they are not supposed to share problems. They may have a boss who believes that once he or she delegates the problem, that unique individual must solve it alone. Or, they might coachingfeel as if it’s not fair to share the problem–that somehow people will take time from their work to help with “my” problem. Or, they have never considered that much transparency.

You can’t ask for help on all problems. Sometimes, when you are a manager, you need to keep HR-type problems private. Maybe you have a fiduciary responsibility to the company, and you can’t share that data.

But, here’s an idea: if you have this problem, chances are quite good other people know about the effects of the problem. You are not the only one living with this problem.

Kim, a program manager, could not understand how to help her teams. They could not discover their interdependencies in time to know when to develop which features. She wrestled with this problem for a couple of weeks.

At our coaching appointment, I suggested she raise the issue to the team leads. She could say, “I see this problem, and here is the effect it’s having on me. Can we solve this together?”

She did. The team leads also felt the pain. They decided to reduce their planning scope, planning for no longer than a month at a time. They used stickies on the wall to see their interdependencies and create interim milestones. As a side benefit, they had to reduce their story size to meet their milestones.

Tip #2: Ask for multiple solutions.

Notice that the team leads helped solve the problem in several ways:

  • They took responsibility for part of the problem.
  • They decided to reduce their planning scope. That helped, but alone it wasn’t enough.
  • They decided to work together, to create a sticky-based planning session.
  • They reduced story size because they realized that having large stories prevented them from working together.

If they had implemented just one of these solutions, they might not have solved the problem.

Tip #3: Ask for help assessing solutions.

Some of the leads wanted to implement their solutions right away. Adam, one of the leads said, “Hold on. I want to see if this is going to work with my team. I’m not sure we can reduce our story size. Let’s involve more people.”

When he shared the proposals with his team, sure enough they were concerned about story size. One of the team members said, “We need to work with our product owner to 0x600-636x310understand how to split our stories better. We can’t do this alone.”

It took them several iterations to learn how to split stories small enough that they could commit to their interdependencies. The team might have resented the solution if Adam had not checked with the team first.

Share your leadership. You will create an environment where everyone leads.

More Learning With Johanna

If you liked these leadership tips, learn more at The Influential Agile Leader. Gil Broza and I create a safe learning environment where you can experiment. We teach experientially, so you have a chance to practice and reflect on what you learn. Please join us at The Influential Agile Leader. The early bird price expires Feb 15.

I’ll be at the Booster Conference March 9-13. I have several workshops and talks:

See my calendar page for all my workshops and speaking dates.

Johanna Rothman

 

Click here to subscribe to our blog!

Footerindesign

 

The Balance of Life and Learning

Tom Burt is a recent graduate of our Master of Science in Project and Program Management Program. He is currently the Administrative Contracting Officer for GSA/FAS/Supplier Management. Below is his story about his journey through e-learning at Brandeis Graduate Professional Studies.

“I always knew I would have to go back to school.  My father presource-schedulingresented a perfect example of that—nearing the end of his career, he had been unable to advance any further in his field because he lacked a four-year degree.  For my generation, I equate that to not
having a graduate degree.  Not wanting to be held back from a promotion, going back to school seemed a necessary evil; however, it was a terrifying thought.  Travelling to classes, giving up nights and weekends, simply finding the time to work on assignments—there was no way I would be able to do all that.  Then a co-worker told me about Brandeis GPS, and all my fears went away.

Online Learning made it all possible for me.  I bought my first home about the same time I started my Program and Project Management degree; due to the nature of the program, I was able to balance the challenges of purchasing a home while keeping up with studies.  Also thanks to online learning, I was able to take vacations during semesters!  On ski trips Slimmedto the western US with friends each year, I started every day with a couple hours of school work (and gallons of coffee) before hitting the slopes.  I also remember a trip to Italy for a family wedding that coincided with Professional Communication.  Had I been enrolled in a traditional classroom-based program, I may not have been able to make the trip; instead, I was posting discussion responses while riding the Rome to Florence train, using the onboard wireless, all while traveling at 250 kilometers per hour!  Grazie Brandeis!  Finally, in the last couple semesters, I was able to attend classes while training for an Ironman triathlon (as much as twenty hours of training per week) while also managing to not get fired from my job!

Graduate school does not have to be a life-consuming event, nor should it be.  There is much to be enjoyeBurtofficeslimmedd in life, such as home-ownership, vacations, and the pursuit of personal goals.  These opportunities absolutely can occur, even while maintaining a career and a family.  Not having to sacrifice other opportunities meant everything to me (and also meant the courses flew by in no time!).  Brandeis GPS was and is the key to this ever-important balance of life and learning.  Having achieved this milestone, I can now start
looking forward in my career, confident that I have the educational qualifications to support my endeavors. ”

Click here to subscribe to our blog!

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)