How to get it done in organisations

I was attending a course during 2016. Attending were a whole bunch of people from many different walks of life, and many different organisation experiences and levels.

Out of the blue, one of my fellow trainees was explaining how they, in their role of working with many organisations on big business-to-business transactions, had discovered a very useful approach to getting things done in their own organisation, as well as client organisations.

"Want something done? Give it to a busy person"

This statement about "how to get it done" in large organisations drew quite a negative reaction from within me.

I realised the statement was right and wrong at the same time.

Busy people have figured out ways to give and to create more value to the organisation - by being of good service, they are asked to do more and more. They figure out ways to do more and more - usually alternative work practices that make them more streamlined / efficient. They become extremely knowledgeable across the whole organisation - knowing who's who, and who to go to directly and for what. Also importantly, they know which avenues to not even bother to try - saving everyone time and frustration.

So...the statement still makes me feel a bit ill, but I also recognise the truth in it. Many organisations I have worked within are literally functioning mostly as a result of these very busy network nodes.

For managers and leaders - look after your ever-busy people - they are busy keeping things moving in the right direction. You may not know what keeps them so busy - but perhaps that's where a little more curiosity and study will be quite revealing!

Agile In Three Or 3 Words

How many times have I heard the following from new clients and other coaches telling stories about their "difficult" clients? That's why I crafted this post!

Agile In 3 Words Is Easy

Actually explaining agile quickly, succinctly and simply for anyone, or any team or any organisation of any size is really easy, if you do the work (inspired by Byron Katie). It's simply you, and everyone in your organisation, and every supplier, client, consultant, advisor, regulator and customer around your organisation offering really often:

"Can I help?"

For agile in 3 words it is as simple as this! The implication is that everyone proacts to help each other all the time with everything from making tea to delivering the most complex system requiring 100's of people interlocking and aligning.

As an agile coach one of the things I look/listen out for when assessing the agile fluency of an organisation is how many times I hear the above line, and especially its followup which is highly noticeable in environments where there is a great deal of proaction - namely:

"Thank you!"

Now, go do the work! Thankyou for reading and supporting! :-)

Agile In A Nutshell Part 2

Okay, so I tried (really really hard) to capture the essence of the vast topic "agile" in my Agile In A Nutshell post earlier ... but something is bothering me. Really.

So I hope you don't mind if I give a second dimension to this massive multi-dimensional concept! This stuff is BIG!

Agile In A Nutshell - Agile Is Now An Umbrella Term

Agile as a mindset and a movement started out in the software development and delivery space. But my first brush with "agile" as a concept was when I was studying business management in South Africa around 2003. The South African management textbook that mentioned "agile companies" stated that the future of businesses relied on them becoming more agile to keep up with customer needs. Although this was after we had implemented much of eXtreme Programming (XP), it was still before (because South Africa has/had very slow internet connectivity, and expensive imported books were scarce) the big software movement really got going worldwide.

I reckon it is likely that the line in that South African management textbook had been inspired by The New New Product Development Game written by the great management scientists Hirotaka Takeuchi and Ikujiro Nonaka in 1986.

But skip to the here and now nutshell point:

Agile is now an umbrella term to mean all of the agile manifesto, agile principles, agile frameworks, agile practices, agile tools, agile approaches.

Basically, any abstract or tangible thing that helps an organisation or an individual, be quicker or nimbler, in delivering value to the end customer. Usually this begins with the mind/thinking framework being applied by the people to the challenges they're responding to.

In other words, it is more important to be agile, than to do agile. For more practical thoughts on agile checkout my collection of teaching/learning agile at What Is Agile For. Thankyou for supporting!

Timebox Rules For Better Time Management

For many years I studied techniques and practices of time management. Partially for my own sanity, and partially in an effort to help my team or the organisation I was consulting or coaching become quicker and nimbler (aka "agile"). I picked up lots of cool one-liners like "survival of the fittest" is incorrect in modern management philosophy - these days it is about "survival of the ones who learn only the right things the fastest".

We Don't Have Time Means We Have Strategic Conflict! We Use Timeboxing To Make This Transparent And Improve The Situation For All!

So on my journey I realised I also had to study prioritisation theory and practices. Surprising to me at the time, time management and prioritisation are 2 sides of the same coin effectively - especially in light of what it takes to survive (let alone thrive)!

Although there is a good Timeboxing writeup on wikipedia, I found it was too theoretical and not usable for people who had not tried many different options, nor did they want to read all the references to understand how to implement!

The below rules I came up with for my experiential training modules are really simple. I have yet to see any better that really help a group or team of people to focus on the most important thing(s) for the most amount of time available.

Timebox Rules For Better Time Management

I think I was inspired by deep reflections on how the agile Scrum framework and how we learn from our errors to come up with these rules that have helped me and many others who have followed them over the years.

Sometimes I vary the ordering by placing #3 nearer the end but for this timeboxing writeup it seems clearer where it is now:
1. Set the end time
2. Everyone watches the remaining time
3. Break large timeboxes into smaller timeboxes
4. Breadth or overview 1st
5. Depth or detail 2nd
6. Stop when time's run out
7. Don't worry - trust the process and stay with it

By following this guideline, the most important thing(s) have been covered, and you can always iterate or run another timebox again if you need to. (ie, use common sense, always!)

The main thing this framework helps with, is moving individuals and people forward. The brain is a muscle, so the more you and your team practice my timebox rules, the more you will get out of this, and achieve.

For example, a 30 minute meeting to make 2 decisions starting at 10am.

1. Welcome everyone and set the visible timer on the table/wall so that everyone knows that the end time is the end time. This is meeting is serious. (30 seconds)
2. Ask everyone to focus on the remaining time and to remain "in the meeting/room" and help everyone stay on focus of the timebox. (30 seconds)

There are now 29 minutes remaining.

3. Start a 3 minute overview timebox to ensure everyone's initial thoughts are heard before going into details. Agree the order of importance of the 2 decisions ("there can be only 1 priority 1")

There are now 26 minutes remaining.

4. Start a 5 minute timebox on the first decision that needs to be made
(assume the group is unable to decide)

There are now 21 minutes remaining.

5. Start a 2nd 5 minute timebox on the second decision that needs to be made
(assume the group is unable to decide)

There are now 16 minutes remaining.

6. Ask everyone to silently reflect on what they have learned or know about decision 1 for 1 minute
7. Ask everyone to silently reflect on what they have learned or know about decision 2 for 1 minute

There are now 14 minutes remaining.

8. Start a 5 minute timebox on decision 1 again
(assume still no decision)

There are now 9 minutes remaining.

9. Start a 2 minute timebox on decision 1
(assume a decision)

There are now 7 minutes remaining.

10. Start a 5 minute timebox on decision 2
(sometimes magic happens, and you don't need the whole timebox!)
(assume people all unanimously agree within 2 minutes)

There are now 5 minutes remaining.

11. Thank all and end the meeting early. DO NOT DRIFT INTO "any other business" or "miscellaneous agenda items". End the meeting. If people want to social then social, but it's no longer a meeting and make that clear!

For further motivation to help you and your team learn this best time management system, check my earlier post on No Time To Improve. Timeboxing gives you the time for doing the right things right.

Thankyou for reading! :-)

What Is Agile For You What Is Agile For Us

So…what do you want to know?

I guess there are 3 readers this agile principles blog post is targeted at:

1. Total newcomer to the whole agile movement/thing
2. Someone who has had some brief training, or read a few books, or someone working next to a team “going agile”
3. Someone who just wants to understand when to reject agile and when to accept agile

What Is Agile For - And How Do I Learn Agile?

Firstly, welcome to this post (actually several that are linked!) about “agile”. I’ve said to myself for a number years, “do not go gentle into that good night” as many many have tried and most have only partially succeeded…the road to hell is paved with good intentions, and many brave good people who tried to communicate their "Eureka!"

To be inspired, and honour William Shakespeare, a little reminder from Hamlet, Act III, Scene 1 with agile updates:

To be [agile], or not to be [agile]: that is the question!
Whether 'tis nobler in the mind to suffer
The slings and arrows [mistakes] of outrageous fortune [delivery in the past],
Or to take arms [learn from the past] against a sea of troubles [complexity],
And by opposing [with a modern, learned mindset and approach] end them [deliver successfully and sustainably with a team that becomes a real competitive advantage]?

Note - I’m not trying to introduce or explain my interpretation of "agile" with this particular post. 

Instead I am going to connect various ways I have taught the 12 agile principles that are behind the agile manifesto to people who have attended my courses or people I have coached or led in organisations. I’ve read (and continue to read) (all) the books, speak to (all) the people and make my own mind up based on my experience.

I reckon if you and your team and/or peers follow the logic of the linked “HowTo Learn/HowTo Teach the agile principles” - and apply my guidance, you and your learners will discover for yourselves what these elusive, ambiguous, uncertain, etc principles mean for you and for your unique situation. And this deeper learning/realisation will set you up for great success in whatever you are going to attempt for the rest of your career.

A pushy declaration, I know. But I’ve been watching the people who really “got it” on my training and how their careers (thanks to linkedin!) have proceeded since 2010…and I am very pleased for them! And even more pleased that a simple manifesto and a few simple principles that were initially thought about in the software development and delivery space that I initially embarked my adult work life in ... have become to be understood as entirely applicable in all walks/works of life.

In the purest nutshell, by the dictionary, agile means "quick and nimble". These days it also has some ambiguous meanings appropriately and inappropriately added to the term, including "10,000 practices you can try to make your organisation quicker and nimbler" - also known as more competitive.

Agile Is [NOT] Too Much To Learn

I’m iterating this post, but over time the dedicated walk-throughs for learners, trainers, teachers, managers and the curious will expand here. Agile is really easy to explain and learn, but challenging to embody. You will see! 

• Agile in 3 Words
• Agile in 4 Words (in response to my earlier "3 word" attempt)
• Agile In a Nutshell
• Agile In a Nutshell Part 2
• Agile In a Nutshell Part 3
• Agile In a Nutshell Part 4
• Agile Principles 101
• Agile Principles 102
• Agile Principles 103
• Agile Principles 104
• Agile Principles 105

What Is Agile For?

My recommended “understand, embrace agile right in mind to do agile right and get the best benefits” and "read them now!" agile books currently are:

Perhaps Agile is not a What, perhaps it is a When, or maybe it is a How?

Thankyou for supporting! Happy learning "to be agile" :-)

My favourite coaching tools: No Time To Improve Agile Retrospective Cartoon

This is a short and sweet one that always brings a little smile to my lips (and some or many team members) when I bring it up in front of the "we're too busy with important stuff" teams during agile retrospectives, or preceding an agile retrospective due to too much resistance because "we are too busy"!

From http://i2.wp.com/ecbiz168.inmotionhosting.com/~perfor21/performancemanagementcompanyblog.com/wp-content/uploads/2014/03/tobusytoimprove.jpg

It seems no one is currently sure where the original is, or who created it. For more modern updates there have been plenty, just search Google!

No Time To Improve / Retrospect As We're Too Busy!

Once we all get past the uncomfortable "Gulp" moment after this cartoon is presented, the team discusses what things are keeping the team members too busy to think about or to reflect or to introduce improvements to the way(s) they are working.

I might even throw in the original Albert Einstein quote:

“If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”

And/or I might put this one in front of the team to reflect upon:

"Give me six hours to chop down a tree and I will spend the first four sharpening the axe."
- Abraham Lincoln

No Time To Improve Because Strategies Are In Conflict (Usually, Deliver! Deliver! Deliver! Unintentionally Making That Axe Blunt, Blunter and Bluntest Of All!!)

If there are still some people needing deeper understanding of the situation they are in, I would introduce them to, and request them to, complete the Covey Time Management Usage Matrix (also known as self-study lightweight time and motion study). After this step is complete, especially including the lunch breaks, random web surfing, tea breaks, urgent phone calls and all the other really important things everyone does with intention or with serendipity at work as normal Business-as-Usual, then people are open to the message, and a humble inquiry!

Respect The People You Are Trying To Help - It Is Their Life!

Always respect the people you are introducing this too, and respect it is THEIR context and THEIR experience that matters, not yours, as external coach / observer / non-invested in the focussed business outcome! And remember why you are introducing this to them - something they are doing must be wasting energy in YOUR ?humble? opinion - not in theirs! Be careful and go very gently and respectfully!

Thankyou for reading! :-)

Best Practice Applied In Wrong Context - Example 1

A friend of mine was ranting the other day. He had just done an iteration retrospective with his development team wherein they took a look at their quality metrics and discovered that "quality" had actually dropped off even though his team had spent more time than ever before on the client's official Quality Process.

I discussed this further with him and we agreed that quality is a mostly subjective concept when it comes to software ... we agreed that it can't be objectively meaasured ... we agreed that it can't be artificially injected "to meet the required metric" ... we agreed that it is something that Software Quality Assurers infer based on monitoring the various metric trends that make sense in the particular environment/context that the software is being developed in/for.

So with all this agreeance I asked him to explain further.

This story is probably a symptom of why I think there is so much cynism in the software industry. Read on if you dare!

It turns out that the client has a well worked out, well defined Quality Process that they are extremely happy with. This Process is guaranteed to prevent massive loss of life/income/spiralling out of control costs/etc etc - you can imagine why a large company invests huge amounts of time and money in creating a bullet proof Quality Process: manage risk, whatever that risk is.

Okay ... so why is my friend ranting? His team followed the process, passed a bunch of procedural milestones apparently and everyone was happy. Yet when he and his team look at the metrics they defined for how they measure quality, they noticed that the number of issues had risen, that some important tests had not been run early enough in the iteration to find issues that they could then respond to before the end of iteration. There were known open issues, and the were issues that had been addressed, but had not been signed off. There was waste accumulating that had not been a problem before.

How did this happen? The people whose responsibility it was to run the tests, to provide the early feedback had been too busy ensuring the team met the Quality Process requirements - they had been documenting, and reviewing and getting documentation reviewed and spending a large amount of time away from the product they were responsible for delivering. They were going on a tangent from users' needs.

And it showed.

There is no happy ending here - key client representatives (project stakeholders, but not users) have to ensure that their organisation's process is followed. Even if they know, and everyone else knows, that the process is not adding value, and that indeed, as above, the process is actually diminishing value. And it appears often that several times a group of client representatives need to experience failure and pain before they will attempt to address a badly formulated, or in the example above, placed, process. Sometimes, regrettably, these lessons are learned during retrenchment phases.

Yuck!

Some Peter Drucker Management/Leadership/Society Ideas

I stumbled on this 5 Things William Cohen Has Learned from Peter Drucker CIO "taster" article a couple of days ago and realised that now is the time when people are going to start talking less and less about what Peter Drucker used to say and what he used to stand for.

From my perspective, his name has appeared in almost every management text book (about 25) I studied during my BCommerce. I even bought 1 of his books from a bookstore once purely because I recognised his name and just knew the sales price was a bargain!

I really hope some truly controversial "new ideas" person starts challenging the status quo once more - it seems like there is a great deal of regurgitation of management thought process going on.

4 Ideas I took away from quotations of his that gave me much to think about:
1. During the early 80's he argued that CEO compensation should not be more than 20 times what the bottom earner in the company was earning.
Imagine what the world would be like if this thought had held...just imagine... all the people ... living for today ... living in peace ... sharing all the world. *sigh*

2. The most useless thing to do, is do something that should not be done at all, efficiently.

Efficiency takes time and money - it costs A LOT! The absolute waste that goes into doing something that should not be done at all, and then making the process more efficient - awful! I guess this is one of my influencers for always trying to find the fundamentals of what I am doing and why.

3. "Management is doing things right; leadership is doing the right things."

Actually this quotation has been driven home repeatedly throughout my limited exposure. I am unsure if my current thoughts are more influenced by study or by experience: There are a huge number of managers (title) without leadership skills, and there are a huge number of leaders (personality) without management skills. When you find yourself in the rare (in my humble opinion) circumstance that there are layers of management with leadership skills all around you, magic is very likely to occur, not only during times of crisis, but also during times inbetween.

4. "The best way to predict the future is to create it."

Strange that one of Peter Drucker's core concepts was Management By Objectives (MBO). Or perhaps it is once again a case of Best Practice being formulated and applied without customisation to the circumstance/environment, and without empowering people to do the right thing as they are being measured on the wrong thing. Regardless - about this quotation - imagine a company culture where everyone is an opportunity seeker. When combined with radical and forward looking MBO, things get interesting, but most companies seem to base current MBO plans on past experience/objectives/successes/failures which is all data driven decision making and does not allow for much innovation and active workforce participation.

Like all people who get used as sources of education and inspiration he had/has many proponents and many opponents. You can read more briefly about him on Wikipedia - Peter Drucker and on the Drucker Institute which houses many interesting articles.

Anyway - I hope you read the CIO "taster" article and perhaps some of the ideas spark your further interest! (let me know if they do!)

As for book recommendations - I can't find the 1st/2nd year text I purchased years ago, but I did look around and find these good looking "professional" sources that I will be buying in the near future:

amazon.co.uk

1.
2.
3.

amazon.com

1.
2.
3.

Lean Software Development

I've been working in "officially" agile environments now since 2000, mainly influenced by Scrum and some eXtreme Programming. A while ago a I did a course on Lean Management amongst other topics and was struck by how some similar concepts (just in time, prioritised work queue, continuous reduction of waste, skilling people, empowering people) seem to be in agile.

The chance to get into my copy of Lean Software Development by Mary and Tom Poppendieck finally came along a few weeks ago after seeing it being referred to in high regard on the web and liking the essays I found on their web site: The Poppendiecks. Basically - "WOW"! This is just really really good stuff. For me it is the kind of jump (up or forward I am not sure) that Scrum makes from Agile fundamentals to real world tools that are completely understandable and easy to try.

The great thing is that they concentrate on fundamentals and then supply thinking tools to help you apply them in your context - ie, they KNOW the lesson that Best Practices are awful as it is the fundamental that must be understood and copied from one context to another to be successfully applied in the new context. Too many Best Practices have resulted in failure and too much waste for my liking!

They touch on some fundamental concepts that are important in modern software development:
- waste
- learning
- last responsible moment
- fast turnaround
- team empowerment
- perceptual and conceived integrity
- holistic view

Why I recommend Lean Software Development:

Reason 1: Identify the value chain from point of need to point of delivery - it is strongly argued by some that anything but coding for that need fulfilment is just a waste of time. IE - as per Agile - lighter weight documentation, lighter weight project management, focus on delivering real value to the client!
Reason 2: Collaboration is better - cross disciplinary people working together are more efficient AND enjoy their work more AND result in a better product AND it is cheaper AND AND AND!
Reason 3: Specific facts, graphs and examples that you can refer to when justifying reasons why you would want to try something different in your own environment, all with a firm basis in Lean Management Theory and which has been studied, well understood, and implemented by some very successful organisations ranging from Toyota to 3M for between 60 and 100 years!!

Thankyou for supporting!