Saturday, 25 July 2015

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 




Saturday, 13 September 2014

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. :-) 



Friday, 18 July 2014

This post is is inspired by  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. 

Sunday, 6 July 2014

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. 

Tuesday, 27 May 2014

The Agile Vacation

My 5 min talk on why Agile can be used for anything is now posted  -- not bad for first time in front of 300+ people if I do say so myself. :-) 


See all the slides on-line at http://www.slideshare.net/Leyts/ignite-waterloo-agile-vacation?utm_source=slideshow03&utm_medium=ssemail&utm_campaign=iupload_share_slideshow 



Sunday, 25 May 2014

When you Hire Smarter do you Really?

An article -- http://www.entrepreneur.com/article/231911 -- I was reading on the 'Entrepreneur' web site read a great quote, "The best investment you can make is to hire people you can trust to take things off your plate." That is so true, and especially with experience as a people manger, it amazes me the attitude of some people.

The reason companies hire is because there is already have too much work for the person doing the hiring with existing resources. That shouldn’t come as a surprise to anyone but surprisingly all too often it is. The following examples are some of the surprises I’ve heard or overheard in the last 30+ years. And yes, in the examples I overheard, I did appropriately challenge the speaker. I can’t guarantee that it helped; just that it happened.

Employees (prospective or otherwise):

“You're here to help me be successful.” No, it's actually the other way around. You’re here to help everyone be successful do doing to the best of your ability the role you were hired to perform. As a direct report to someone, your manager will in turn help you help them be successful by using the skills you espoused as within your possession during the interview process. You must sow before you can reap anything. BTW, everyone in a company of two or more people is a direct report to someone else; even if you’re the President and CEO.

“I lied to you because I didn't think I could trust you, and when I was fired that proved I was right.” No, you were fired because you lied to my face and proved I couldn't trust you.

“I'll work with you but I won't work for you.” No, if you're a new hire with relatively few years of post college work experience and someone is going to take a chance at giving you a job, damn right you're going to work for them. A smart business is not an autocracy but it ain't no f@#king democracy either.

Managers:

“I gave you the job; now you're on your own.” No, if you're going to be a people manager, manage your people. You don't want to do that? Okay, maybe it's you that's in the wrong position.

“I was here first, I know better.” No, because if you're the smartest person in the room about everything that needs to be done then you're hiring idiots .... or maybe it's somebody else that's the idiot.

“I expect people to leave their outside lives at the door, and behave in a professional manner while in the office.” Professional (aka 'ethical')? Certainly. Leave their lives at the door?! Really?! You do know you're actually hiring people not robots; right? Sure, to the best of a person's ability they should manage their emotions rather than the other way around. Empathy is a critical factor in leading and managing ... bear with me here ... P E O P L E.

All these people and many others haven’t a clue when the term “servant leadership” is used. It does not mean the leader becomes the servant. It means the leader provides a service in their role as a leader to create something bigger than themselves. And from yet another article “Learning from and acknowledging mistakes requires the humility that Level 5 Leaders display. Level 5 Leadership, according to Jim Collins (no relation), is what separates exceptional leaders from all others.”

Knowing all of this perhaps I was then somewhat overly surprised when I read another article -- http://www.entrepreneur.com/article/232914. This article labels flexibility and drive as personality (78%), cultural alignment (53%), and then skills (39%) as the areas for job opportunities in the future. This actually scares, yes 'scares', me.

Yet from reading this article I further appreciate what I've been hearing some senior economists say over the last year - "there will never again be a company that lasts for over 100 years". I hope the article is a misinterpretation of the study. If charisma and group think are valued more that skill and respecting each others' individual differences then the probability is a whole lot smaller towards ever creating in the future innovations like the iPhone, object oriented programming, or a flexible process that will leave Agile in the dust the way Agile has waterfall.

I listened to a Sr. VP at Google tell a crowd of wannabe employees about a year ago that he didn't care if somebody was the best programmer in the world if they didn't have the skills to get along with those they needed to work with. There is a lot more damage that one developer can create that would more than offset them writing code day in and out. And everyone deserves to feel good about going into work every day they go.

Okay, not everyone, not those who have the perspective that it's all about them and anyone else left can have whatever scraps are left-over.

Not those to manage to what I call the "dumbest common denominator". The perversion of the 'no kid left behind' strategy in the 70s and 80s created class agendas where mediocrity flourished. This was 'easier' than empowering the best and the brightest to go as far as they could, to leverage their own innate talents to go beyond on their own, and use that extra bandwidth available to the teacher to help the stragglers get over the hump. This is the premise of apprenticeships that have worked the world over for hundreds of years. This also opposes the short-sighted mediocrity of unpaid internships. Now of course anyone who can afford to do this may actually be the most qualified for the role, however, those who cannot are never even given the opportunity for those people or companies to ever find out. And as my statistics professor said, “you can’t prove a negative.”

I still have some hope that some of today’s leaders and those into the future are seeking principles over popularity (personality) but if this second article is correct that is not the case. And if that is truly indeed the case, all I have to say is "may god help us all". History has given us examples with companies like Nortel, Enron, MCI Worldcom, NCR, and many too numerous to mention that when popularity and charisma become paramount the company doesn’t last long. Certainly each of those companies thought they were making the best decisions when they started hiring charismatic individuals over those with more valuable ‘skills’. No one intentionally makes business decisions to proverbially slit their own economic throats, but when they do make decisions that do just that then everyone suffers from stockholders to the least skilled laborer to some degree.

So this is where we come back full circle to where I started this post. Hopefully you are hiring smart rather than mediocrity. Hopefully they can do things you can’t or better than you. And if not that, hopefully you are hiring apprentices who are willing and able to learn.


What does this all have to do with project and program management? Well, the same as any other management role; to get things done through other people. Hopefully, most of those people are smarter than you in what they were hired to do. And hopefully they equally recognize that you are smarter than them in what you do as well.

Sunday, 11 May 2014

Status reports versus Progress updates

The difference between a status report and a progress update.

As much as the uninformed would have some people believe, no it's not semantics.

For example, a team member has a series of tasks to complete a user story; a requirement. Let's say those tasks are to load and stage the latest development build, and then execute a series of tests to determine if what is new in that build 1) does the functionality that was added, 2) has not broken anything that used to work, and 3) does all of that with the same or better system throughput performance. Let's also say that the original estimate for that work is three-and-a-half days. Further, let's say that equates to 7 story points.

A status report is "I've got the build and I'm continuing to stage the software." A status report or update is focused on the past up to that point in time. And until somebody invents a time machine where people can go back in time to to change things, this is a waste of people's time; including the person giving the update.

A progress update is "I've got the build, I started to stage the build this morning, and I ran into one small problem, so I spoke with Julio and he was able to help me out right away. He discovered there was an error in a default setting for our test environment. So all things considered, I believe the work will still be finished as planned on Friday." A progress update or report is future focused. It focuses on where things are headed and gives people a proactive opportunity to avoid risks while that work is ongoing or for the next time such a set of similar tasks is being performed.

In the status report, there is no way to know whether the work is on, ahead, or behind schedule, or worse, completely roadblocked. It does not support clear visibility into the progress of the work being done. No one knows to offer help if the tester is roadblocked, and for all anyone knows what is occuring with these series of tasks could be the first indication that the project could be completely riding off the rails.

I've heard some people say "well, that's the project manager's job to ask questions to clarify that." And for me, that is completely and utterly obtuse for two reasons.

One, if the project manager has enough time to remember to stay that on top of every task then either the project isn't very complex or the project manager is being under-utilized. Either way the company is wasting money.

The second reason is that I suspect in a lot of situations those same team members would probably next be screaming about being micromanaged if that was happening. And if they aren't, hopefully the project manager is thinking something like "my god, what am I doing here?! Isn't there something better I could be doing with my life?!" In short, the project and the organization in actuality are circling the drain.

In summary, a progress update creates value-added visibility with opportunities to create even more value beyond that specific point in time. A status update takes people away from the value-add they are doing in their individual jobs so they can hear each other ramble on for probably longer than necessary, add just another layer of distraction that further reduces their value and productivity in each of their roles, and creates unnecessary overhead.

Think I'm wrong? Listen to the updates from yourself and other team members in your next scrum session, stand-up meeting, or whatever you want to call it.

Saturday, 10 May 2014

Paying back ... or at least forward

"Tell me and I forget. Teach me and I may remember. Involve me and I learn (or I will understand)." 

For me, this is a great quote, that I believe has been around in various forms since the days of ancient China.

The challenge though is how rarely it seems to be applied. Perhaps being the least in the last decade compared to ever in history.

What I mean is ...

To 'tell' someone something they must be listening closely enough to ask questions if you are being vague; or at least for you to clarify for them so they understand you.

To 'teach', one must be willing to be taught. This applies to the student and the teacher, and I remain astounded by the number of people who consider themselves no longer a student as soon as they graduated out of school. As stated by an old proverb, "Only a fool knows all."

To 'involve' is no more of an isolated category than the previous two. And like the other two categories it is a relationship of sorts between the provider and the receiver. It is also a more involved or deeper relationship because it requires more effort to complete. It also creates more value for the short and the long term. As in the movie "Mr Holland's Opus" this teacher learned at the end of his career when he was feeling at his lowest the true impact of his efforts. Most teachers have their students for a few months and then are never seen again. The truly great teachers have students who stay in touch, make the effort to say hello on the street, or attend show their appreciation in other ways with a positive impact that lasts a very long time. 

The question that remains is whether you want to be average or mediocre in the things that only the unique you can do. I'm also neither saying do this for free. Part of the value measurement of any effort is based on what people are willing to pay for it. 

That said, over the last couple of years especially it seems there are more and more greedy and unethical businesses who have been discreetly re-implementing indentured servitude or slavery, and some I'm sure believing themselves wonderful human beings for doing so. They tell themselves they are offering an education that those students would otherwise be excluded from. Their slaves are given labels like intern or football scholarship recipient and that's supposed to make it okay. Back when I was young and for hundreds of years before that when people did a job where they were also learning something it was called being an apprentice or in a co-op program through the institute of higher learning; and we all got paid.