Seeing the forest for the trees

Some people based on their aptitude for project management and level of experience intuitively see the things others don't see or recognize are even factors of (or for) consideration.

For example, there are critical and chaotic situations where an existing team member, lead or manager that for one reason or another wants or feels the need to do something before they know if that action will make the situation no better and sometimes make things worse. This is the scenario of being busy for the sake of being busy, and is analogous to why doctors hate patients that go on-line and prescribe for / diagnose themselves using some web site (e.g. WebMD).

Now there is a subtle difference between crisis and chaos that sometimes gets blurred in the heat of the moment. Crisis in the context here meaning that there is a real or imagined urgency and need for immediate action. Chaos may or may not come about as the result of a crisis. Chaos in contrast is when people are attempting to do something ... anything to avert further disorder or confusion (sometimes insistently and with great fervor and determination), and it can be made better or worse by actions taken. Thus, I believe likewise that a difference exist between reacting and responding to a certain stimuli -- e.g. an angry customer call. I'll leave that for another post though.

In either case, you need to decide whether you have a crisis or chaos. That might also mean you need to go first to where they are mentally and emotionally and prod them along with you to enable them to see the forest for the trees. Also recognizing some people have gotten themselves deeper into those proverbial woods than others by the time you get to them. Thus, it will require more time and effort on your part to get them to where they need to be.

In all interactions with others (to paraphrase the Dalai Lama) it is important to 'seek to understand before offering one's understanding' and provide a level of respect you would most certainly expect for yourself. Because they didn't understand the question or the situation does not preclude you from doing the same. I recently witnessed a public interaction where I thought one of the two people was about to say "no, duh!" and even though neither did it wouldn't have surprised me if that happened.

Comply v. Commit

A leader with a vision they absolutely believe in and understand themselves is most evident through how they communicate it to those they need to rely on to convert it from dream to concept to implemented reality. They have the ability to talk about that future, that vision, with such clarity it is as if they are talking about the past. That's where the difference between commitment or compliance begins.

We all know there are times when there is a high level of urgency or some crisis and compliance is needed; where the need to get people started and a solution implemented. These are the exceptions.

We also all know at some level the value and benefits of getting people to commit to something and yet it's never too far away until I see another example of "because I said so", ego-driven politics. The following is my short rant of sorts to just get this out there in the hope it does someone good.

The differences between compliance and commitment is regardless of whatever or how much passion you have for whatever you're trying to achieve. Here is a brief list of those differences.

Compliance ---

• People may comply but you still can't force anyone to do anything -- you will fail to fully achieve your vision / objectives ... no matter how much your response to this is "oh yeah, I'll show you!"
• Whatever you're actually able to achieve -- it'll cost more to get there. Maybe through money, time, bad blood, whatever, ... you can be assured it will cost more.
• It'll also cost more to maintain if for no other reason than those who do not agree or believe in your vision (because you didn't get their buy in) will do what they want when they think they can get away with it ... guaranteed.
• ... or maybe they just don't care because you already showed them you don't care.
• Drivers try to enforce their vision by introducing a down side / threats; negative reinforcement

Commitment --- 

• Decisions are made and communicated based on objective, critical reasoning (not subjective -- yes, yes, we already know your mommy said you were wonderful and perfect. She's probably the only one and maybe a few others that think so), and so ...
• people understand why
• they appreciate it's importance and impact
• there is a WIIFM for them that isn't based on a threat
• enforcement is mostly self-perpetual through positive reinforcement

So    much     easier.

A mentor of mine once told me they focus on sharing what they are for rather than what they are against, because what you put out comes back to you; what you sow is what you reap. Good advice. Wish more people knew it.

We Tried Agile and got Nothin’

Anyone who knows me first hand in or from the corporate world knows I’m first and foremost an Agilist. Whatever my title is, at my core I’m an Agilist. That means I live and breathe the principles of what it means to be Agile, and I’ve done so for quite some time now. Sure, I can do and follow traditional practices when it’s called for, but when it isn’t it tears my heart out. When I write ‘Agile’ it’s not a typo either; anyone can be ‘agile’ without being ‘Agile’ and some companies out there may still be doing it very well.

A conversation I recently had with a senior R&D manager included her saying “there are a thousand ways” to be agile. And while that is true there are just as many or more ways to pretend to be agile and not reap any of the benefits that exist by truly being Agile. The following platitudes are a few examples to highlight why some companies have ‘adopted’ or ‘embraced’ agile practices and are still barely or no further along in enhancing productivity, quality or engaged teams.

The companies and teams who say they’re taking a ‘blended’, ‘modified’ or ‘hybrid’ approach to Agile have most certainly adopted something out of a book or webinar on Agile but at their core they’re still 100 percent pure waterfall. I’ve lost track of the number of examples I’ve witnessed or read about that show how much this is the case, and how many billions of corporate dollars are lost every year as a result. It’s enough to almost make a grown businessman cry.

A very wise uncle of mine a long time ago shared with me Mark Twain’s definition of an expert, “someone from out of town.” I’ve always remembered that and been saddened within my career that so many others did not have access to uncles like mine. How that applies here is when companies choose preferred employees with strong influencing skills to attend a conference or something on Agile. That in and of itself can be very good, but only if those same employees are personally interested in the topic have something to lose if they don’t adapt to and adopt to what they learn. Similarly, if you’re going to spend budget money to send those people somewhere, please, please, please make sure it’s from someone who is actually qualified and certified to do that. For example, someone with CST after their name would be good. About a year ago I was speaking with someone in a team lead role at a company who went with the lowest bid. That trainer told the attendees that testers should “go for coffee” while the developers plan the backlog. That company has been adopting agile for about six years now and still hasn’t seen one quantifiable improvement in how they manage projects or products.

Too many times I’ve heard executives and senior managers talk how important this all is to them and in the next breath say the equivalent of ‘find me something I can call agile that means I don’t have to change anything but gets me all the benefits’. Too many times I missed the chance to say ‘you need to go big or go home’ even if you go in small steps. After all, you must learn to crawl before you can walk, and you must learn to walk before you can run. I seriously doubt they would’ve listened anyway. Speaking to those people any more than I have is like spitting into the wind, and has earned me and many others the label and back-handed compliment of being a “purist” among those same people. I don’t take the insults or suggestions that I’m immature in the business world too seriously though, and I hope those others feel likewise. I’ve already empirically proven time and time again that doing Agile as intended will reap the benefits many once though impossible. And to offer some inspiration for some of those others who are only now becoming inspired by Agile, even out of the mouths of babes comes wisdom. Those other naysayers and belittlers on the other hand will never envision let alone earn the ability to achieve anything close to the benefits reaped by other companies who do embrace Agile for all its worth. They and their companies may even lament one day ‘if only we had known!’ Sad thing is for them and all the others they were supposed to lead, they did.

Finally, like any activity, being Agile takes practice to get good at it. Some would even say 10,000 hours of practice. So send people on courses, attend conferences, hire a consultant, whatever you need to do to grab that ‘Agile’ brass ring. Just don’t keep doing what you’ve always been doing except now with some agile term on it that sounds good. You won’t reap the promised benefits (no matter how many excuses are forthcoming) and it tears the heart out of us who really care about this stuff.

The definition of a Leader

I re-watched the Peter Mansbridge open access interview of Justin Trudeau last Wednesday, November 4.

What was perhaps the most inspirational for me was when they were recording him on a teleconference with grade school students. Part of his response to one student was, "A good teacher is not someone who stands up in the front of the class and gives out all the answers. A good teacher is someone who knows the challenges their students are facing and helps them solve all those challenges and get the answers."

When asked about it afterwards he replied, "Being a teacher is what I am."

What speaks to me most about this is that it would be very easy to replace the word 'teacher' with the word 'leader'. This is more than leadership, this is the heart of servant leadership. Time will tell for sure. At this rate; however, I may be witnessing the first politician I will ever believe in.

Kanban’s jump onto the Agile bandwagon

As an agilist with a love of knowledge one of the things that irritates me to no end are when someone modifies the definition of something to suit their own marketing or other agenda. Thus, let's first create a framework for what is to follow.

History

Kanban at its most basic level is a Japanese word that means visual token or instruction card, or yes, there are as many ‘roughly translated …’ definitions out there for ‘kanban’ as there are kanban web sites and product solutions out there on the interweb. :-) 

Many years ago and even some sailing vessels today use signal flags. These flags were introduced at some people’s estimates approximately 300 years ago. And they are part of the maritime standards and laws still today; although I would hazard to guess at the percentage of people today with boats that could read them. The point here is not to suggest signal flags are Agile. They are nevertheless ‘instruction cards’. As such, the message below could mean “AGILE” or “I have a diver down and you need to stay clear unless you’re a pilot at which you should approach at low speed while I alter my course to port (the right) because the ship is quarantined so when I said ‘port’ before I actually meant starboard.” You decide. :-) 

Eventually Toyota started using the principles of kanban for manufacturing in the 1950s. 

And seriously, at none of these times within any of a multitude of this or other examples anywhere across the decades or centuries ago was anyone thinking "Agile" project management. They weren’t even thinking about JIT either for that matter until the 1960s in Japan and the 1980s in North America. 

The word, the principles of kanban and signal or instruction cards existed all the same.

Skip forward to the Present 

The popularity of Agile gaining as much momentum as there are people abusing it to serve whatever agenda they have, and for that matter people and companies applying it as intended and gaining huge benefits as a result.

There are also an incredible number of people and companies schlocking the next best mouse trap. Intermingled among them are some really awesome products that can support and enhance the effectiveness of teams within companies to achieve results unimaginable until they actually see it for themselves. 

So here are some general good practices in no particular order you may just wish to follow if you’re going to use ‘kanban” and “Agile” in the same breath. 

• Unless you're a team of 3 or less and the project isn't that complicated or complex, it needs to be so much more than three columns of states of work encompassing To Do, In progress, Done or some variety of those labels. If that describes your team and the project, sure use kanban; you might just love it! Just don’t call it Agile … at least just not right away.

• The principles of Lean and Limited WIP are important. Create distinct rows for features and priority.

• No tool is Agile if neither it nor those using it are adhering to the principles behind Agile. And in the context of this article in particular, the first value statement in the Agile Manifesto itself … “Individuals and interactions over processes and tools”. That leads me to another factor all too many take undue liberties with; the word is ‘over’, not in place of, or instead of … but that’s another article for another day.

• Whatever tool you plan to leverage, a tool with a Personal Kanban and work by person views so you can see who is overloaded (or overloaded themselves) and is blocking or blocked by others will very likely at one time or another be great a feature to have available to you. Some tools address this by creating Done columns in between functional group columns, or colour-code the story cards.

• If you've got multiple cards that someone says they all have together in their own personal kanban you really should be asking yourself why. Seriously, I've seen project teams of about 20 people with 3-month development windows where they've created over a thousand story cards. Now that's an example of where those deconstructing stories should be checked for OCD! :-)  In all seriousness, any team that does this has with very high certainty eliminated any scheduling benefits available from taking an Agile approach to what they are doing.

• The point at which some process manager or anyone else over-complicates how a kanban approach is used that is also the point you are no longer following the principles of kanban -- as I believe is described so very well in the video attached to http://whatis.techtarget.com/definition/kanban as a good example. 

Conclusion

Kanban can be an incredibly awesome and effective way to manage projects. Kanban is not Agile on its own unless the specific guiding principles also applied to it. For that matter, no tool on its own is Agile.

References

https://www.crisp.se/file-uploads/kanban-kick-start.pdf 

https://kanbanery.com/ebook/GettingStartedWithKanban.pdf

http://agilemanifesto.org/principles.html 

You're Agile ... really?!

One really easy way to determine if you are doing Agile or not is to ask if part way through the project, the company could release what you've done so far and start making money from it. Not whether the business will; whether it could.

And as those who know me personally have heard me say many times, ... There is a big difference between big-A Agile and little-a agile. You can be 'agile' without being Agile, but you can't be Agile without being agile.

That for me is what is at the heart of a lot overly complicated answers I see on the web. As apparently said by Albert Einstein, "If you can't explain it simply, you don't understand it well enough." And based on what I've read about Al in the past, 'simple' refers to how complicated something is, not how complex it is, and being able to describe something so everyone can understand it at some depth.

If you want to be truly, over the top successful in business these days you need to understand and build towards the MVPs (minimally viable products) from your customers' perspectives; not yours. Customers' needs change over time so adaptability built into your development practices whether you're creating software or anything else. That said ... remembering all the while that your customers may not know what exactly it is that they want. That's why you're here. (see / Google Henry Ford and Steve Jobs quotes)

Want change because your company doesn't do that well? Adopt new habits and eliminate old routines. Meaning that if all you do is slap agile labels on the way you've always done things, or worse, apply the parts of Agile that align to how you currently think and ignore the rest you might as well be teaching a pig to sing. As the idiom goes "it's a waste of time and all it does is annoy the pig". 

That's my rant for today ... maybe I'll have the where-with-all to read some more 'Agile' (or is that 'agile') spam in my inbox after I take the dogs for a walk. :-) 

This post is is inspired by Tim Rahschulte and his LinkedIn discussion in the Program Management Academy group.

Some of the practices that have worked best for me are:

1)  Educate people early to appreciate (if not understand) that a big project and a program are two different things. There should be at least some delta in the benefits metrics you're measuring because of that. 

2)  Do it, whatever it is, only if the benefit can be described in tangible, non-political terms. If "because it sounds good (ego)" is the only reason to do it, it probably should not be done.

3)  Recognize the mole hills that will become mountains and deal with (perhaps even laud) them as successful learning opportunities.

4)  Appreciate the current speed at which you are traveling. There is an optimal point between managing to the "dumbest common denominator" and the soldier's creed of 'leave no man behind'. It's important to regularly assess whether it is still optimal.

These four things won't guarantee success but ignoring them will almost certainly refute the opportunity to achieve it. I (like many a reader here I'm sure) have seen way too many really good strategic initiatives become question-marks and dogs from stars and cash cows by sponsors and other clouted stakeholders who make it about personal egos rather than corporate benefits. 

How safe really is SAFe?

I've been hearing a lot more about the SAFe framework these days. A lot it sounds like business people (excluding actual Agilists) who have yet to learn the lesson of the trojan horse -- the original one from that war a few millennia ago. Either that or at least believe that it applies to them.

SAFe can work but only if one remembers two things.

1. what the Agile Manifesto says -- the first line in particular, and
2. it's always about People --> Process --> Tech/Tools ... in that order.And as I spoke about at the Ignite Waterloo 14 event, people need to remember that to achieve successful results that order never changes.

Want further evidence to this? See . . . 

As KenSchwaber wrote on his blog "we cannot buy our way to a better future", it takes hard work. Sadly, as even I have seen all too often, there are way to many armchair quarterbacks out there who think reading a book, a few articles, and attending a 2 or 3 day course will make them experts. The rescue project management contracting I did for a few years about a decade ago proved that is not the case.

Another author posted "While SAFe is about alignment, transparency, program execution and (code) quality it’s about how YOU are going to implement the ideas, principles and practices in YOUR environment. In the end it’s the implementation that matters: It’s you, your colleagues, your shared goals/values and the business value you produce."

Ron Jefferies wrote "SAFe wraps those ideas in a package ... to appeal to today’s managers and executives who do not understand Agile, but who know they have a problem to which Agile may be the solution."

The short answer is that SAFe can be a safe and effective tool if the tool is used to supplement the concepts of an Agile approach and have them applied by true professionals who truly understand and appreciate the concepts behind being big-A "Agile". 

A little over a century ago practically anyone could call themselves an engineer. It took the failing of several bridges and one in particular that caused a huge loss of lives for business people, governments, and society at large to appreciate the gravity of the errors in that belief system. True professional engineers wear an iron ring to remind themselves of that. Hopefully one day in the not too distant future business people, governments, and society at large will stop wasting billions of dollars and tens of thousands of hours of people's lives on an annual basis, and they will also appreciate what true professionalism is as it applies to project, program, and portfolio management.