Visualizing a portfolio

[Glenn]

I'm working at a reasonably large organization and I've been asked to help them reveal their system as it relates to portfolio, intake of new projects, and capacity. I would expect to uncover:

• High WIP for the given set of people
  
• Non-dedicated teams -- "team" members work on multiple teams
• Help to visualize the organization's capacity to deliver
• Help them plan when a new product/project can be started

I would like to have a workshop where they visualize their system by putting cards (stickies) on the wall where each card represents a project. I was thinking that each card would have the number of dedicated people working on the project, the number of non-dedicated people along with a percentage (e.g.: "0.6 : 2" where 0.6 is the total percentage of 2 people that spend their time on the project), and last the number of team months left on the project.

I was also considering connecting the the non-dedicated box on the card to each of the other non-dedicated boxes where the people are working. So, if a person is working on projects A, B, and C then there would be a string between each of A, B, and C. I'd expect it would get quite messy quite quickly.

My questions to the group are this:

Has anyone run a workshop such as this?

How was it different from what I describe?

What worked?

What did it reveal to the attendees?

Was this impactful to the attendees?

Glenn

[Jon Kern]

It is hard to comment on your proposal without a conversation. But it sounds pretty technical and kind of complicated to draw all of those dependencies… Sounds like MS Project and PERT charts and resource loading — GAK ;-)

I cannot tell if your mission is o document their “status” or to help them deliver better?

I cannot tell if this is a company working on software for themselves — like part of their business involves software and it is always changing and growing. Or is this company one who does projects for others as an outsourcing firm?

FWIW: I was called in to a large org a few years ago to ostensibly help them with "portfolio management."

Then I started pre-meeting with some folks and realized they did not have a portfolio management problem. They had a people problem, so I worked on helping them understand that and move forward.

—————————————————————— 

Don’t know if you need any suggestions on how to help them deliver better, but here goes…

Based on some works from John Cutler I read years ago, and some other works by the likes of Intercom and Basecamp, I have switched my thinking about products to an outcome based perspective — and no so much project-based. Subtle, I know.

What outcomes are expected to be produced by the organization — not just the development group? And then what project(s) and people are assigned to the outcomes?

How many things are run in parallel (slowing down delivery?) vs in series (work on the most important thing)?

How do they prioritize the expected outcomes? Do they have the right business folks available to help reduce each expectation to the simplest thing to try so that you shorten the feedback loop and reduce the dev time?

How well do they break down their major feature sets to issues that are sized properly to make the chance of guesstimating more accurate?

How often do they need to know when things can be started, and why?

I prefer to work on things based on priority and only worry about start dates if I absolutely have to.

Jon Kern

blog: http://technicaldebt.com

twitter: http://twitter.com/JonKernPA

github: https://github.com/JonKernPA

--

---
You received this message because you are subscribed to the Google Groups "Lonely Coaches Sodality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lonely-coaches-so...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yves Hanoulle]

what is the problem you are trying to solve? 

Op di 2 okt. 2018 om 15:41 schreef Glenn <gwwa...@gmail.com>:

--

---
You received this message because you are subscribed to the Google Groups "Lonely Coaches Sodality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lonely-coaches-so...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- 

Yves Hanoulle - 0476 43 38 32

• Events I co-organize
• CoderDojo Ghent: http://gent.coderdojobelgium.be/
  
• 
  
• Community events that need your help:
  

• Carbon Manifesto translation http://carbonmanifesto.org/translate
• CoachRetreat in your country >> mail me
• CoderDojo's all around the world looking for coaches. This is the Belgium subscription page https://www.coderdojobelgium.be/nl/vrijwilliger-worden
• www.agileconferenc.es all agile conferences worldwide, maintained by the community
  
• Community Tips for hiring a great team: http://www.hanoulle.be/hiring 
• Who is agile "your country version"  >> mail me
  
  
• books I helped create
  
• 
  
• NEW: Tips from the trenches: scrummaster https://leanpub.com/TipsFromTheTrenches-Scrummaster
  
• How to organise a CoachRetreat: https://leanpub.com/CoachRetreat 
• 96 Visualisatie Voorbeelden https://leanpub.com/Visualisatievoorbeelden  
• The ScaledBallGame: www.ScaledBallGame.org
• PairProgramming workshop: http://leanpub.com/pairprogrammingworkshop 
• Leadership Game: https://leanpub.com/TheLeadershipGame 
• All my books: https://leanpub.com/u/YvesHanoulle

[Glenn Waters]

Well, the problem they have stated to me is that the organization is doing way too much -- over capacity. Their solution is to keep slicing and dicing people (resources in their words) across multiple projects, cause if we keep getting started no one will be upset. As a result there are few projects that have dedicated people on them.

So my thought was let's visualize this complexity. I'm looking to create an visceral reaction to spark some change first see the complexity (chaos?) that exists and second start the discussion about what to do about it.

I'll respond to Jon now... more there.

[Allen Holub]

Hi Glenn,

Jon’s point about outcomes is relevant. What’s the outcome of this exercise?  In other words, which problem will you move towards a solution? I don’t know what it means to ‘reveal a system’. Is that their wording or yours? Simply describing a system isn’t usually particularly valuable. I find that people often understand the problem pretty well; it’s the solution that eludes them. You list a bunch of things you *expect* to uncover, along with implied solutions, but you don’t say that you’ve actually uncovered anything, and who knows if the solution you have in mind is correct in this context. I’d start there. Do an assessment and make a list of actual problems (not solutions) that you observe. Collaborate with the execs and identify the most critical one, and then come up with some indicator that you’ve made a dent in the problem. Might be a metric, might be a new behavior you’d like to see, but there has to be something visible. Then work on that specific problem until you move the indicator. Collaborate with the teams and have them come up with some way to move the indicator. Do that. If it doesn’t work, try something else. Repeat. 

-Allen
___________________________________
Allen Holub
al...@holub.com
@allenholub
+1 (510) 859-3620 (skype ID: allenholub)

linkedin: http://linkedin.com/in/allenholub

[Glenn Waters]

As to my mission I'd say the client and I are aligned -- the goal is to help them deliver better. My thinking was if we can visualize what exists now then the insight will help talk about where to change.

This is an IT organization developing for mostly internal users of the systems.

There is both a portfolio problem (way too many projects for the number of people) and a team problem (teams do not have dedicated people).

I'm fully behind the thinking shifting from projects to products, and the outcome thinking that goes with that. It may be part of the discussion depending on how the discussion goes. Its not the most important thing to talk about right now.

Where I'm headed is:

• I would like get them to move towards teams with dedicated team members
  
• Bring work to the teams rather than bringing (parts of) people to the work
• Create a cadence, say every three months, to review what the current product states are and decide what is most important for the next three months
• Get a level of involvement from the business so that the team has enough vision to be able to build something and get feedback quickly

Before I forget thanks for the feedback. The responses and having to explain what I've been thinking has helped me immensely! I'm a lone coach on the ground in a large organization. Having this list to talk on softens the loneliness!

Glenn

[Ari Tikka]

In my experience the portfolio management and related problems start upstream.

Management realizes that we have a problem. Without taking the energy to learn the problem and it's relation to the whole, they delegate the solution to an (execution) project. Next problem next project.

Every project tries to solve their local problem, competing with others about resources.

The portfolio management then faces the request from the projects: "We are late and need more resources to solve our problem." However, because the problem statement and the project outcome are vague, it is really difficult to prioritize the requests. Random resourcing follows.

The solution would be to do more work earlier, in the problem domain. Then we can have smaller and more specific actions and outcomes that we can prioritize.

This is difficult, because it requires time and collaboration from many important (business) parties that are used to the privacy on their own turf, etc.

Sorry about the brevity and abstractness...
Ari

--

[Jon Kern]

Your extra info helps.

This analogy may not work, but I like to quip:

“What is the fastest way to get 6 things done?”

pause… tap toes… twiddle fingers...

“One at a time!”

Not six all started at once, and you move from one to the next, turning a knob or two, then eventually one starts to get done… if you wait long enough.

That’s how you make 6 shish-kebabs on a bed of coals, turn each one and move to the next.

That’s not how you make software, at least not efficiently.

So, maybe forget trying to visualize… that sounds like you need to justify trying something different. I never understand why internal teams continue to do the same process that they know is not working as well as they think it could. Just do something — anything — differently and see what works best.

Just take half the projects/teams and instead of running them in parallel run them in serial fashion and start delivering faster ;-)  

But if you had to reveal the insanity… Just put it into a MS Project type of system. No sticky notes needed. When the projects are context-switching, add a percentage lag to reflect the “spooling back up to speed” think time for context switching.

Then you can do what-if scenarios — like change the resources from 50% to 100%, drop the context-swishing “tax," and watch what happens to the project milestones.

Even if you do this as a simulation of sort in case the real data is elusive. It may serve a purpose of illustrate the effects — and the “tax” — of doing things in parallel vs serial.

If the company foolishly thinks that a bunch of things being partially worked is better than working things to conclusion before moving onto the next, they probably will believe MS Project and PERT logic.

Another thought, could there be a mish-mash of types of work confusing things? Are there some projects that are “must have” firefighting, bugs, and the like? And other types of projects that are more new feature-esque? And the same people are doing double-duty across critical bugs and new projects?

Jon Kern

blog: http://technicaldebt.com

twitter: http://twitter.com/JonKernPA

github: https://github.com/JonKernPA

[Glenn Waters]

Thank you Ari.

The biggest upstream problem that I'm seeing is not saying NO! Everything is important so let's get started! And then the spiral just spins a wee bit faster.

Glenn

[Sam Laing]

Hi,

What would happen if you gave them an "A"? So assume they know exactly what is wrong and why. That they already know the answer and something is stopping them from implementing this.

Now, what would change?

How could you help them voice this to each other safely and without blame?

My 2c...

Sam

[Glenn Waters]

Thank you Jon!

To the question at the end of your email, yes "teams" are doing both feature work and maintenance work for other products. That's going to be a necessity for the foreseeable future as the number of systems to support far exceeds the number of teams. Where I've been coaching on that topic is to allocate some percentage of their time that goes to handling prioritized support work. I've also been coaching that all work, feature or support, comes to the team to figure out how to handle.  They are not there yet but the understanding is coming along.

I was also going to run Henrik's "How Long Does it Take to Write a Name" game. Maybe the game with a good debrief is enough.

Glenn

[Glenn Waters]

Hi Sam, when you say "gave them an A" I assume you are saying "give them a top mark"? That is a fascinating idea! I have no idea how that would work out and need to sleep on that for a day or two. Maybe an Open Space... hmmm. Thank you!

[Yves Hanoulle]

there is a multitasking game that I learned from Alan Cyment

http://www.hanoulle.be/2012/01/multitasking-game-from-alan-cyment/

for me, it shows very nice what multitasking does.

I also like to explain a story on 2  jobs

job A takes 5 steps

job B takes also 5 steps

for the sake of the exercise , A and B take as long

now imagine We first do 

A1, A2, A3, A4, A5, B1,B2,B3,B4,B5

(I draw that with two lines of five boxes 

A tasks in green

B tasks in red

then I redraw 
A1,B1,A2,B2,A3,B3,A4,B4,A5,B5

And ask what is the difference for client B?

No difference, finished at the same time

And what is the difference for client A?

They usually feel tricked by then

==> A get's the results much later

and then we assume swaping task, does not costs us any time (we all know this is wrong)

so why do we do this?

I know only 1 real reason, so that we can tell client B, that we starting

giving the impression B will be finished faster

yet this shows it impossible

And then the sucker question, with how many questions are you busy?

(your exmaple was 5 or 6)

oh but Yves, sometimes we are blocked.

oh, really , why are you blocked? we are blocked, because the resource down the line is also working on 3 projects and she is finished slower because....

Combined with the game from alan, people also understand that almost everyone restarted from the start, because they los track of where they were. (and does his ever happen in real life? I just count the number people looking at their shoes (or my shoes if they are extraverts)

y

Op di 2 okt. 2018 om 22:01 schreef Glenn Waters <gwwa...@gmail.com>:

--

[Dale Emery]

Hi Glenn,

Well, the problem they have stated to me is that the organization is doing way too much -- over capacity. Their solution is to keep slicing and dicing people (resources in their words) across multiple projects, cause if we keep getting started no one will be upset. As a result there are few projects that have dedicated people on them.

“Doing way too much” is their solution to a deeper problem. It’s a flawed solution.

The deeper problem is that they don’t know how to respond when customers are upset.

Slicing and dicing is not an attempt to deal with doing too much. It’s an attempt to avoid the conflict that ensues when they tell one of their customers, “We’re going to give your thing a lower priority for now.”

The fantasy is that if they slice and dice thinly enough, they can tell everyone “we’re working on your thing,” and that everyone will be happy (or at least less upset) with that.

It’s a common fantasy: http://cwd.dhemery.com/2005/11/multitasking/

A major flaw of that fantasy is this: It does not prevent conflict. It merely delays conflict. Slicing and dicing means that nobody gets what they want any time soon. Customers will eventually (soon?) come to care far more about the lack of progress than about “we’re working on it.”

And let’s imagine that, somehow, people were temporarily happy with “we’re working on it.” There’s another factor that will likely lead to even more work: People (and other living things) are acquisitive beasties. Satisfied customers often ask for more: http://cwd.dhemery.com/2004/08/locof/

“We’re doing way too much” because whenever our customers are upset, we take on more stuff rather than say no, or not right now, or we’ll put it in the queue behind this other work we’re doing.

They’re going to have to work on prioritizing, and on dealing with the inevitable conflict that comes their way when they give some customer’s work a lower priority.

Cheers,

Dale

[Yves Hanoulle]

yes ignoring problems, only make them come back worse

Op di 2 okt. 2018 om 22:59 schreef Dale Emery <da...@dhemery.com>:

--

[Ron Jeffries]

Glenn,

On Oct 2, 2018, at 11:48 AM, Glenn Waters <gwwa...@gmail.com> wrote:

Well, the problem they have stated to me is that the organization is doing way too much -- over capacity. Their solution is to keep slicing and dicing people (resources in their words) across multiple projects, cause if we keep getting started no one will be upset. As a result there are few projects that have dedicated people on them.

Interesting that they know what the problem is: doing way too much, and don't see the solution: don't do so much. 

I wrote this Petition the King article ages ago about that very topic. Also this Work in Process article. Also Kate Oneal wrote about Funding Projects.

If I were going to try to convince the folks, I'd use simple drawings (like in those articles) or some fun exercises, like this one:

https://lithespeed.com/the-name-game-a-multitasking-game-for-agile-teams/

Or make up some exercises:

What about a variation on the penny-flipping game, where we use four different kinds of coins, pennies, pickles, dimes, quarters? The point of the game is to build four products, each product consisting of ten or 20 coins of a particular kind. Maybe we have a Product Owner, if they're scrummish. Each Sprint, the PO sets down maybe 6 or 8 random coins, face down. The team has to flip each coin face up, wrong-handed, then line up all the so-far done coins of a given type in a staging area for that product. Time how long it takes if the coins are selected randomly. Time how long it takes when they do all of one type of coin until that product is shipped, how long for all.

What if they had to build some simple thing out of Lego? Each product uses different color legos, or parts from a different lego toy. Team gets parts at random, time how long until done. Team pulls parts from sorted piles as needed to build first one, then next, then next. Measure time to 1 happy customer, 2, 3, all ...

Do a card game on the wall or on the screen. Object is to build a line of red, yellow, green, blue cards, one for each product. Same thing.

There are a zillion ways to make it graphically clear that they'll do better if they have the nerve to do only as many things as they can build dedicated teams for. 

The problem, of course, is that they already know this. As Dale points out, the problem isn't that they don't know. Someone somewhere needs to toughen up and figure a way to do what they already know they need to do. 

Fun!

Ron Jeffries

ronjeffries.com

Apparently, this IS my circus, and, quite probably, these ARE my monkeys.

[Keith Ray]

"New policy: every time we add a new project to be done by the same people, we have to tell all the other projects that their projects will be finished later and done slower."

--

C. Keith Ray

[Ron Jeffries]

:)

On Oct 2, 2018, at 5:45 PM, Keith Ray <keit...@gmail.com> wrote:

"New policy: every time we add a new project to be done by the same people, we have to tell all the other projects that their projects will be finished later and done slower."

Ron Jeffries

ronjeffries.com

It's true hard work never killed anybody, but I figure, why take the chance?

-- Ronald Reagan

[Glenn Waters]

Thank you Yves! Alan has come up with so many creative ways of simulating work! I have not seen this multi-tasking game before. I plotting how I might use it.

Glenn

[Glenn Waters]

Thank you Dale. Every now and again it is wonderful to be reminded that human creatures have a few default modes. I'd thought about the need to prioritize, but didn't make the link to avoidance of conflict. I appreciate that. It helps immensely in framing the discussion that needs to be had. While I thought I had read most of your blog posts, I don't recall reading the LCOF one before. So nice. Thanks again!!

--

[Glenn Waters]

Thank you Ron! I love the Kate stories. I had not read the one you sent below. I think a few of the links that you and Dale have sent would be good to send out before a workshop to prime their brains on where we are going and help move them to some concrete actions.

Perhaps you'd like to come to Play4Agile North America next year, love to have you share some of those game ideas. Just sayin :)

Glenn

[Jon Kern]

Great new book by Basecamp authors, been reading it the past two days.

“It Doesn’t Have to be Crazy at Work”

I can’t say enough good things about the book. It resonates deeply with me.

Jon Kern

blog: http://technicaldebt.com

twitter: http://twitter.com/JonKernPA

github: https://github.com/JonKernPA

[Mark Levison]

Damn you Jon Kern for making my reading list larger and heavier.

On Thu, Oct 4, 2018 at 1:53 PM Jon Kern <jonk...@gmail.com> wrote:

Great new book by Basecamp authors, been reading it the past two days.

“It Doesn’t Have to be Crazy at Work”

Only one question - does it say very much that the people on this don't already know?

Cheers

Mark

[Sam Laing]

yup - ditto... but didnt see a kindle version? Damn... 

--

[Keith Ray]

It's on Amazon in Kindle and Hardcover

https://www.amazon.com/Doesnt-Have-Be-Crazy-Work-ebook/dp/B079WV79TK/ref=sr_1_1?ie=UTF8&qid=1538705088&sr=8-1&keywords=it+doesnt+have+to+be+crazy+at+work 

--
C. Keith Ray

[Sam Laing]

Chuckle not in NZ ... luckily I also have a US account :) Thanks!

[Rob Park]

For the smaller items/projects, I love that “petition the king” piece. I’ve used it a lot. Thanks Ron.

Recently, working with bigger orgs and larger portfolios of large projects, cutting WIP has been a focus, but the challenge has been which of the 20 projects should they choose? For that I’ve been having success with using Cost of Delay & Weighted Shortest Job First. There have been some good eye openers with visualizing this 3 months will unlock $100k vs this 6 months will unlock $1mm.

It has helped in cases too where the team manning the intake funnel needs to rationally manage projects and not simply succumb to which exec is screaming the loudest... at the moment.

@rob

[Glenn Waters]

Thanks for that Rob. Dang, back to rereading some cost of delay books! 

There's a pretty good free ebook out there that I've found useful: http://blackswanfarming.com/experience-report-maersk-line/

Scroll around half way down the page to get the link. It's short and easy to read. 

Glenn 

______
Sent using an itsy bitsy keyboard. Expect typos and brevity.

[J. B. Rainsberger]

On Tue, Oct 2, 2018 at 9:31 PM Glenn Waters <gwwa...@gmail.com> wrote:

 

The biggest upstream problem that I'm seeing is not saying NO! Everything is important so let's get started! And then the spiral just spins a wee bit faster.

I'm late to the party, so maybe this doesn't help, but I think it could illuminate the situation a lot to ask them "What do you like about the way that you're doing things now?" Maybe they'll talk about avoiding conflict or some other uncomfortable thing, and then they might feel ready to confront that thing.

--

J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca ::
blog.thecodewhisperer.com

[Wouter Lagerweij]

Hi Glenn,

Royally late, I know, but...

I like and recommend all the use of games and such to help create understanding. I've also had clients that were hard to convince that their situation was like the game. The 'Real World' is often seen as much more complex...

So,  in addition to helping them understand these type of issues in the abstract, you might also think about making the problem more visible in the current work. That can be simply by actively monitoring blocked stories in the teams, perhaps helped by a weekly report on time spent blocked, or even a daily scrum-of-scrums type get-together where we share blocked issues. Making the problem more viscerally visible might encourage adoption of the ideas you're wanting to try.

If there's specific people/skills that teams are having to wait for, making a visible queue somewhere for their time might also be interesting. As long as someone is also working on keeping them from burning out from the pressure:-)

Wouter

--

---
You received this message because you are subscribed to the Google Groups "Lonely Coaches Sodality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lonely-coaches-so...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Wouter Lagerweij          | wou...@lagerweij.com

http://www.lagerweij.com  | @wouterla

linkedin.com/in/lagerweij | +31(0)6 28553506