The Mysterious Q word 0

Qi…. It’s a word and a concept you may have already heard of – but maybe you don’t know much about it. What is Qi, really? Well – it’s a unique form of energy secretly hidden away within your body.  Let us introduce you to Gong. Combined, the word Qi Gong translates to ‘Life Energy Cultivation’, and is the act of harnessing and using this energy to achieve your body’s full potential. It’s practiced by millions around the world every day, and it’s beliefs have spawned many similar practices such as yoga, tai chi, chakras and acupuncture to name but a few. QI Gong

For some of you Qi Gong might not be a new idea, but for those of you discovering it for the first time, perhaps no one is better equipped to tell you about it than Lee Holden. Lee has hosted a number of hugely popular Qi Gong shows on PBS since 2005 and has become a household name in the process. I have teamed  up with Lee to give you access to 3 free video lessons that will show you how you can start practicing this ancient art straight away – no experience necessary. That’s the beauty of Qi Gong, anyone can do it! It’s called Qi 101 and you can access the lessons for free

Those who have seen Lee before will be happy to know he hasn’t lost his fun and easy approach to energy…  And those who haven’t will experience an easy and adjustable introduction to Qi Gong that can only be found as part of Lee’s new project – Modern Qi Gong.

“Lee has a gift to take something very complicated and to make it very simple and direct without losing the essence of it. I have tried Tai Chi and given up because it was too complicated and time-consuming. I feel that the way Lee teaches Qi Gong is practical, not complicated, and not time-consuming. I got pain relief within 2-3 days. The pain is gone; it’s amazing!”

Discover QiGong

The above links are affiliate links

Is this the Future of Meditation? 0

Do you meditate? Or are you at least curious about how this ancient practice can help you? Yes? Well we have a gift you’re going to love from our friends at Mindvalley – one of the world’s biggest online personal growth publishers.  omlife

It’s a free meditation audio. But with a difference. Because you’ve NEVER heard anything like this before. The audio uses a next-generation sound technology called Omharmonics, Omharmonics is a revolutionary audio meditation product designed and developed after a year of devoted attention by Mindvalley and a team of world-class consciousness engineers. Powered with binaural beats, heartbeat synchronization and ambient sounds, Omharmonics stimulates your senses in a positive way and is scientifically proven to eliminate internal and external resistance to allow you to reach an optimal meditative zone in a matter of minutes!

The truth is, most of us struggle with meditation. Many of us can’t shake off mental chatter. We fall asleep. We get restless. We can’t find the time to practice. Omharmonics makes all these problems obsolete. Grab a pair of headphones, set aside a few minutes, and be the judge: Go here to download and listen to your free Omharmonics audio.

This audio could transform your meditation AND your life.

The above links are affiliate links

Should Agile be used as Your Portfolio Manager? 0

A part 2 of yesterday’s blog postbased on this related podcast and transcription: Leffingwell on the Lean Agile Train. Dean Leffingwell is a consultant, entrepreneur, software executive and technical author who provides product strategy, business advisory services and enterprise-level agility coaching to large software enterprises.

An excerpt from the podcast:

Joe: When we go into the portfolio management, should that be based on  Agile?

Dean Leffingwell: Well, there’s a question because it won’t start that way. First, I want to give credit where credit is due and not just pick on the PMO or the other PM guys that were trained. The PMO’s have built governance models around the waterfall life?cycle model because we taught them that was the way to write software. We have new ways that we’re writing software now, and we have to teach them those too. But in the meantime, their governance models and all of their activities are focused around the milestones and things like design reviews and test plan complete, requirement sign off, and code freezes before defect triage, we taught them all that stuff. We shouldn’t be surprised as agilists when we go to instill and install Agile and they’re saying, “That’s just great but you still have to meet the phase to exit gate which requires that the design is complete.”

Yet, if you go to those teams and say, “When will the design be complete on this project?” They’ll look you straight in the eye and say, “The day we take it out of maintenance.” Not in the phase two milestone review. There are a lot of legacy mindsets that are there, but they’re not there because we have people that think in legacy terms. They’re there because that’s what we taught them.

I think we have a responsibility to educate them with Lean thinking, and I have better luck looking at things like the way milestones… Let’s just say there’s a design review milestone on a program, and the program is late. I ask the PMO, I say, “Well if the program is late does the review move to the left or the right?” Meaning forward in time or later in time and they say, “Of course the review moves later.” I then comment to the fact that what you’re saying then is that the later the program is the less often we look at it, right?

They go, ” Well that’s not very Lean thinking.” Because that’s the opposite of what we should be doing and since we don’t know if for sure it’s late or right, why don’t we just do periodic review on a cadence and we’ll review maybe all the programs on the same cadence and look at whatever they’re doing. But if they’re not creating design specifications for us because they’re Agile, they’ll be creating code. Why don’t we assess the code? Let’s ask them for a few key measures around the code. Let’s ask the product managers or customers or whomever how it is they see that the see that the code is developing.

Let’s look at the facts. Let’s look at the quantitative objective facts of how the code is evolving. Because in Agile, there will be no excuse for not having code. While they may not have some of these other things that you’re used to seeing, they’ll have a test strategy. They may not have a test plan because to write down their test strategy into a plan, number one; they have a model that’s integral. It’s no longer separate activity. Number two, they only write down what they need to write down, and they’re not going to write that down just to give to somebody else. So, let’s just look at the code.

So when you approach the boundary of a PMO, the way I like to approach it is that your governance model got us here. The waterfall development got us here. We’re moving forward. We’re not just going to throw away governance, right? We still need oversight; we need to know how we’re spending our money.

We still need to drive the teams to the right vision and the right programs. That hasn’t changed. But the practices that we’re using have changed materially. So before I just make these milestones go away, let me give you some suggestions for new ones.

How about this; how about each program has a milestone review every 60 days and every 60 days we’re going to look at the current amount of working code, the current defect count, the current feedback from the customers and the current plans for distributing that piece or how it’s doing if it’s already distributed. Get their mind around assessing the actual use of the product or actually looking at the application rather than looking at their intermediate artifacts that we used to create, the code was all being done in parallel before we couldn’t really run much of it. All we had were these artifacts.

The code was so hard to change we had to try and get the requirements right, so one of those artifacts was our software specification. Well, we don’t do that anymore. We do have software requirements. They’re called user storage and acceptance criteria, but we write them just in time.

We want to make sure even though it can seem fairly pointed sometimes, and sometimes the PMO has looked at the mother?ship of all impediments, I don’t look at it that way. I look at it as one of the elements of the enterprise that’s going to be transformed as well. There again, you’ve got to go in with different tools.

They can think Lean; they don’t care about a daily stand up or how a Scrum team works. That’s not part of what they do. So taking them, teaching them Scrum it’s kind of an interesting experiment, but they don’t do Scrum. You got to speak in their terms, and that’s basically the business economics, how Agile and Lean thinking drives business economics and the principles.

Again, some of the principles of product development flow that I like to lean on Reinertsen’s work for that they can use to help improve the overall enterprise performance.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Keys to Building a Lean Agile Software Enterprise 0

Dean Leffingwell is a consultant, entrepreneur, software executive and technical author who provides product strategy, business advisory services and enterprise-level agility coaching to large software enterprises.

Related Podcast and Transcription: Leffingwell on the Lean Agile Train

An excerpt from the podcast:

Joe:  What are the keys to building a Lean-Agile software enterprise?

Dean:  Working towards my one annual presentation, I do one trade show a year. I go to the Agile conference every year. It used to be Agile XP, and that has just grown tremendously and it’s a high-value conference. So I’ve been reframing the way I describe the way I see large enterprises being successful around five basic keys. Now I’ll describe those keys here. It might be a good way to approach the things we’re talking about. Key number one is, not everything is a user story. A user story is a really great invention. It came from XP, the user voice forum, which is, as a user; I can perform this activity so I can get business value. This is just a fantastic breakthrough in our thinking. But user stories are small because they fit inside iterations, and there are lots of them. So at the enterprise level they don’t scale very well and that’s why you see in my book “Agile Software Requirements” a three?tier, three?approach of user stories, features and epics and even a fourth year if you will which is the investment themes that drive all that.

So my first bullet thought is got to be smarter than just taking everything to a user story. The second key is at enterprise scale the way we’ve rolled out Agile historically which is a team entered a time or a Scrum mastered a time is simply too slow. So, I like to think in terms of Agile programs and not just Agile teams.

Agile programs are oriented around this construct that I’ve roughly described as the Agile release train, which is a synchronous set… Or a team with a synchronous set of iterations all timed together, working together, doing their planning, their commitment, or execution of their feedback together as one fractal above an Agile team, which has exactly the same pattern.

Thirdly, architecture emerges in Agile. It’s part of the manifesto, but I got to tell you at enterprise-class scale it can emerge in some really bad ways. And if you’re sticking together an entire portfolio or you’re doing enterprise-class business applications you can’t expect any one team or any half?a?dozen teams to have a real view of how that all needs to work together or what types of governance needs to be applied to those systems.

So, as I wrote in “Scaling Software Agility,” I’m a big fan of architecture and system architecture in the enterprise. And I call that intentional architecture, which may be flies in the face a little bit of some of our thinking. There’s some of the agilest thinking about architecture, but it can’t be strictly emergent in my view. So enterprise systems record potential architecture and I have a model for that. That was brought to me by others that I had the great privilege of working with a couple of enterprises that were quite Agile and also needed to re-architect their systems. I call that re-architecting the flow. So that’s item number three.

And fourthly if the teams are Agile and the programs are Agile, but the enterprise isn’t, if the portfolio is still being treated with fixed budgets where people must be assigned to tasks. And in month nine, in order to justify keeping them on your program or the portfolio function is driven by those who understand requirements independent of implementation and communicate that and make commitments on behalf of the teams and programs, then you’re not going to be very Agile either. And there is a set of legacy minds that are there that I think we have to cope with. So that’s item number four.

Lastly, and this is where I’ve been spending most of my time lately, and so many things are obvious in hindsight. I think we’re all brilliant in retrospect. It’s just the going forward part where we question our sanity. Lastly, your enterprise is going to be no leaner than the executives thinking and no matter what you try to do at the team or program level, until your executives are totally on board.

Not with Agile so much because Agile for them is good, sounds great, but they don’t do Scrum. They either think their teams are already empowered or maybe that’s just not a big concern of theirs, depending upon their cultural bias and mindset and history. So, we don’t have a lot of tools for them in Agile. You can’t take them the manifesto. It’s useful, and they’re interested in that but it doesn’t drive their lives.

It’s tough to communicate with high-level executives about Agile practices in a way that’s meaningful for them because they don’t do any of it. But Lean, they can think about and understanding the value stream and understand how certain, let’s just say, governance items really caused delays in the value stream and understanding that the total tack time, the touch time, we put on a system is a small percentage of the total delivery time; getting them thinking about delays in the value stream and what causes those delays and what they can do about it, is just a better approach.

I’d like to think in terms of two sub-aspects. One is Lean education and I have one go-to source now, which is Reinertsen’s new book that I like to use with executives and have them read it and sit down and discuss some of those key principles. Then lastly, you’ve got to show them how their enterprise is going to look like after the transformation, and I call that the Agile Enterprise Big Picture or the scaled Agile Delivery Model. If they don’t know how it’s going to look later they’re not going to be very comfortable with a totally self-organizing complex dynamic system that’s just all going to work out.

Even though that’s largely the case, I think the pattern of how teams and programs get organized and how values flows; how they’re involved as fiduciaries of the enterprise level; how the governance model works; how they drive the portfolio, is critical to them. Because if they can see and after they know the current picture, they know how it works now and they know there’s some challenges but they wouldn’t be reconsidering it ?? but if they can and after it just makes their life a heck of a lot easier. I call that Lean Education in the Big Picture.

So those five keys, not everything’s user story for sure, think in terms of Agile programs not just Agile teams. Admit that our large scale systems require intentional architecture. Think about some of the legacy mindsets we’ve had in portfolio management and how to address those. Then also understand that we’re going to be no leaner than the executive’s thinking. Those are the keys that I currently keep in mind whenever I approach a barbarian at the gate of the not as Agile an enterprise it wants to be.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info

Can You Assign Work Better? 0

Jim Benson returns to the Business901 podcast next week. His company Modus Cooperandi combine Lean principles from manufacturing, Agile methodologies from software design, and the communications revolutions of social media, as process and tool infrastructure. Jim is best known for his seminal work, Personal Kanban. He is @ourfounder on Twitter. Our conversation centered on his new work, Why Limit WIP: We are Drowning in Work (MemeMachine Series) (Volume 2). Why-Limit-WIP

An excerpt from next week’s podcast: 

Joe:   What are some of the roadblocks I’ll have in starting to assign WIP and getting started in doing a better job than what I’m doing now?

Jim:      The roadblocks are many, and they will come from several different directions. We don’t naturally limit our work in process. It seems alien when you start doing it, and you frequently end up with people doing work that they’re not even aware that they’re doing. So you’ll come up to somebody, and you’ll say, “What are you working on?” And they’ll say this and you’ll say, “I don’t see that on the board…” and they’re like, “Oh, it’s not.” And it’s not that they’re hiding and doing hidden surreptitious work, it’s that they really didn’t know that they were working on something else because we get distracted and we just do things and we have internal narratives that drive us in these directions. And that’s fine, but the problem is that we’ll do that, and then we’ll find out that that little thing that we started doing has suddenly become its own project.

One of the funny things is we’ll setup a personal Kanban for people and they’ll come in in the morning and there will be eight tickets that they know they want to blow through over the course of the day, and they’ll get through the end of the day and they would have only done two of them. They’re like, “Oh my God, I don’t get anything done!” And then we’ll start talking about it and it ends up that they did four or five other things that were very important, it just wasn’t on their board and they never actually thought to put it on their board.

In the Covey matrix, coming back to the Covey matrix where you have the urgent but not important tasks – this is when people come into your office and say, “Do you have a minute to talk about this…” and then an hour after, they leave. Maybe that interruption was bad, but maybe it wasn’t. If I have four people walk into my office over the course of the day and they each talk to me for half an hour and the first three totally waste my time, but the fourth one has some idea that makes the company an extra $7 million or makes me an extra $7 million, that would be nice; were those other three waste?

We spend a lot of our time trying to kill off meetings and trying to stop people from interrupting us, but we’re actually at work in a company to be in the company of other. We’re there to collaborate and sometimes you have to go down a couple of dead-ends; you have to exercise a couple of options that don’t pan out in order to find that fourth one that really does. In knowledge work, there is a cost of obtaining knowledge that is usually paid at the price of doing things that don’t obtain knowledge. We can’t know ahead of time what that fourth meeting is going to be. It’s not like, “I only want the fourth meeting…”

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Understand the Processes, Understand the Organization 0

Customer Focused Process Innovation: Linking Strategic Intent to Everyday Execution is compilation of David Hamme’s thoughts and processes that he uses. The  related podcast and transcription can be found here  Fine Tuning Your Company Processes.

An excerpt from the discussion:

Joe: Why do think we need a process? I mean why do we need a process for innovation, why aren’t we, having that one brainstorming session and putting the post-it notes up and “Boom, let’s go try this.”

David: That’s a fantastic question. To me, processes are the underlying mechanism. It’s the construct that really defines how it would work. If we really want to understand what goes on inside of an enterprise, we have to understand that it consists of hundreds or thousands of processes in most cases. They’re all interconnected. They span different departments and different groups and how they work in totality is how that organization or how that enterprise creates value. If you don’t look at that viewpoint, I don’t think there’s a construct out there that operates nearly as well. But, once you have that and all that totality of that network, it becomes a blueprint for anything that you want to do in the future.

I like to use the parallel, “If you’re building a skyscraper and you want to do an additional on it or on your home or whatever building, at the end of the day you start with a blueprint. So often, efforts inside companies don’t start with that blueprint. It becomes just what you said. Let’s sit in front of a white board and throw things up there. The problem that I have with that is you’re creating a lot of waste then. You’re not using structures that already exist that you can leverage. You may be creating a whole new organization when you don’t necessarily need to. So, if you want to make it methodical, specific and design the organization to the task at hand, you really have to start with that blueprint.

The concept I use it is what I call an enterprise process blueprint. It’s a high-level view of an organization from a process perspective, and it’s analogous to a traditional org chart but with several differentiators. First is I put the customer on there. My thought is the customer is the supreme of whether you’re successful or whether you fail. The other one that you want to, please to gain market share or if it’s not a for-profit corporation, it could be your stakeholder that you want to please, that you want to provide value to. If the customer’s on there and you map all your processes to that customer, now you really understand what is the flow back and forth between you and the customer, what are the connection points, what are those things that you can do to delight that customer and as it focuses down it replaced the org chart which I mean the org chart is a command and control structure that really kind of shows who reports to who. It doesn’t really show how work gets done.

Enterprise process blueprint gives you that view of the workflows, how they flow out to the organization, so when you’re planning innovation efforts you can go back to them and say, “You know what, we can leverage as part of our organization to do this.” And, there’s just a lot of power in starting from something and having a framework as opposed to just letting it be kind of, you know, spitballing things in the air to see what comes out. I find for innovation one of the worst things you can do is put up a suggestion box. You can get a thousand ideas there but you got to weed through them at the end of the day because they’re not grounded in what the problem really is or what you’re trying to solve for or the customer you’re trying to delight, they really don’t give you a lot of value or as if you can say very specifically, “We want to delight this customer and this is what our current processes are.” Often, the ideas become much more focused, become much more meaningful, and that gives a lot more value and it really accelerates your innovation process.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Are You short of Resources? Capacity? 0

A thought leader in organizational project and resource management, Jerry Manas is frequently cited by leading voices in the world of business, including legendary management guru Tom Peter. Jerry ManasYou may know Jerry from his book, Napoleon on Project Management: Timeless Lessons in Planning, Execution, and Leadership. This interview centered on Jerry’s latest work which is a subject matter that I have been spending a lot of time with lately, The Resource Management and Capacity Planning Handbook: A Guide to Maximizing the Value of Your Limited People Resources.

Download the MP3

Business901 iTunes Store

Mobile Version

Android APP

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)