Friday, 11 April 2014

Google Cloud Platform Roadshow: Manchester

Welcome landing slide


I had the good fortune to be at Google's Cloud Platform Developer Roadshow, which kicked off in Manchester's TechHub this week. The combination of my early arrival, never having visited the old TechHub building, not being able to get into the new building, the TechHub website still showing the old address, Google showing the new one did make for an interesting rush as I did wonder where I was supposed to be. When I then incorrectly found myself back at the old TechHub offices, I wasn't alone it seemed as I met a few students who also didn't get that memo :)

In the end, we got ourselves back and were rewarded with coffee and breakfast pastries, which given I hadn't had breakfast, more than made up for it. Even if It did mean my name badge curled up almost instantly due to the amount of very brisk walking my 118kg frame (+7kg laptop bag) had done back and forth.

Curled up name-badge worn by Mr Radiator :-/
Having lost my original seat, I then initially got relegated to the cheap seats, so figured I best move :)

Not a great view :-D

Introduction to Beer and Salvation

Doug Ward (@SimplyDoug1987 on twitter) ran through the usual housekeeping and informed us that we mustn't stop to collect personal belongings but to save the beer. I thought that was a good point as nobody usually likes a warm beer. But as as Brad Abrams, Group Product Manager introduced the agenda, the Fireside chat did make me wonder if avoiding warm beers were really the motivation to save them after all :)

Doug Ward keeping house


Keynote

Brad Abrams ran us through a quick whirlwind of the Google platform. I was pretty familiar with this already, though I don't use Google AppEngine much. I overheard Brad talking to a group and mentioning that they are in the process of supporting SQL Server 2008 R2. Not quite clear as to how as yet myself. Still quite intrigued and so I gather, was Mandy Waite when I approached her about it towards the end of the day.

Google's Cloud offering




Developer Advocates Mandy Waite and Laurence Moroney joined Brad after he presented the agenda, to walk us through a number of deep-dive demos of Google's AppEngine, including presenting the new OnDemand pricing and Sustained Use discounts for any usage over 25% of the month on each platform. This is a very useful discount and after I questioned Brad on whether or not it had to run continuously, he confirmed that it didn't. It just had to use 25% of the 10 minute blocks of a whole month of OnDemand use.

New Google AppEngine Pricing Model


For those outside the Microsoft sphere, together with the drop in OnDeman pricing, this suddenly makes the Google AppEngine a very attractive proposition. I intend to cover why in a later blog post, but like other models on the market, this has the ability to create a maximum amount of compute and storage costs that you have to pay per month, but applies it on what you actually use, unlike AWS and Azure, where you either commit to reserved instance pricing, or 6 to 12 month blocks up-front, which hits agility and also fixes your discount to a level above your real OnDemand usage (if you pay up-front and use significantly less than you forecast). See the Moz story for an example (though this appeared to be an issue with technical best-practise and inefficient use of AWS, which in my experience of PR and marketing agencies, is unfortunately all too common an occurrence).

The focus was very much on mobile development and there was a lot of mobile developers in the audience as well as some familiar faces on the Manchester tech scene (See the back of Saftag's head below).

Shaf Chaudry showing sponsors around  before the start

Demos

Mandy and Brad ran through the creation of a Sudoku solver and Meme Maker using Python, this was supplemented with an Andoird App written in Android Studio (which by the way, I really like! It's much better than Eclipse, which I've done a bit of work in before, and brings a lot of Resharper like functions to the IDE - which I really missed in Eclipse). Requests were made through JSON secured with OAuth tokens.

Mandy and Laurence both demo'ed the boilerplate for hosting through the AppEngine API, demonstrating the use of Python scripts and the gcloud CLI tool to manage the OAuth keys (which is a much more long long winded process) and testing functions through Google's Developer Console. I've used this before to generate requests and test access to Calendar info for some .NET projects I've done and to be honest, it's best of breed at the moment in this particular area, but AWS still hold the balance of power across the board IMO.

Brad explained that the environment gives Google developers a free Git instance and runs your unit tests if you have them. This then displays the results in the console for you to check on. This is a pre-ested commit (gated check-in) so if it fails, it doesn't deploy to live. This is nice, but AWS also has a free git instance. The key difference is that Google's Cloud Developer console has in browser editing, which automatically runs the tests again and deploys it to live, but also puts it in the Git repo for your team (or another dev team) to pull later. This is crucial, as cross team development needs up-to-date and common code bases to use and the ability to force changes for DevOps/App Support staff, but still maintain the consistency of the code base is essential!

Brad and Mandy run through the storage of images in buckets for the meme-maker demo app

Conclusion

All in all, there was a good number of take-aways. Given my current working platform (Microsoft) I don't see myself changing off AWS any time soon. That said, the MS hold has more or less lipped away from a large number of small business and start-up community groups. So I can see this featuring very heavily in interaction with those markets going forward.

Google AppEngine definitely offers a good (and quick) alternative to AWS if you want to host OSS platforms. I think they're still a little slow on the release of new language support, as they pretty much had the same languages on offer as two years ago. That said, there are some very nice touches in AppEngine, such as the ability to SSH into your Linux VMs and work on them locally. However, if your main work is PHP, Java and especially Python, you can be up and running with a fast platform, very quickly and cheaply.

All in all, a good half-day. The beers didn't need saving either :)

Thursday, 27 March 2014

If tech doesn't mirror customer value, YOUR customers should leave!! (A view on Netcetera's recent epic-fail)

I am sat here on another dreary morning, having waited over 24 hours for my company website to come back up. I am betting on a race for my hosts to get it up before the DNS propagates my website away from them and what is now a truly awful service.

I am going to take an unprecedented step and name-and-shame a hosting company for appalling service throughout this year. The company is Netcetera, and despite winning awards in the past and being a MS Gold Certified Partner, their shared hosting performance as of this year has been catastrophically bad. I have yet to experience a hosting provider have this level of failure (in both size and frequency) in such a short period of time.

It's when things go wrong that you get an idea of what goes on in a system or organisation of any kind. Indeed, in software, that's what happens when you use TDD to determine how a piece of software works. Change the code to the opposite and see what breaks. If nothing, then there isn't coverage or the code is unimportant. Indeed, companies such as Netflix use a 'chaos monkey' or error seeding practise, to test their organisation's resilience.

The problem is dealing with risks doesn't give you kudos. You don't usually see the effect of a risky event not happening, but you definitely get the stick if it does. So your success means nothing happens. For a heck of a lot of people, it's just not sexy. That's the project manager's dilemma.

Since mid-Dec 2013, certainly for me, there have been issues that have affected me and my company in some form on average roughly every 2 weeks. A screenshot of my e-mail list of tickets is given below:

Some of the email tickets from the last 3 months, showing 6 major issues, some required a lot of my time to help resolve


Yesterday morning at around 7:30am GMT, Netcetera had an outage that took out a SAN due to a failed RAID controller (OMFG!!! A SAN!). This took out their issue ticketing/tracking system, the email system for all sites and control panel console for all shared hosting packages as well as their own website client area. So customers couldn't get on to raise tickets, couldn't manage their account, couldn't send or receive emails, couldn't get on to fire of a DNS propagation (which is all I needed to do). This rang huge alarm bells for me, as the last issue was only 3 weeks ago and I started the process of migrating off Netcetera then. I got an AWS reserved instance and have been running it in parallel as a dark release to smoke test it since then, just waiting for a case such as yesterday to happen. My only regret is not doing it sooner.

What does this failure tell you

The failure of the RAID controller immediately tells you that the company obviously had a single point of failure. In a previous post, written after a month containing two high profile catastrophic failures in 2012, I explained the need to remove single points of failure. This is especially important with companies in the cloud as resilience, availability and DR should be their entire selling point as PaaS and IaaS providers. This is an area Netcetera are touting now. If you can't manage shared hosting, you are in no position to manage cloud hosting. Potential customers would do well to bear that in mind.

If their reports are to be believed, in this case, everything went through a single RAID controller on to a SAN which covered those Netcetera functions and customer sites. This is a singe point of failure and don't forget, is also your customer's dependency. RAID was developed specifically to address availability and resilience concerns and comes in many flavours/levels, including mirroring and striping, but it appears that doubling the RAID controllers or 'bigger' entities (such as another SAN or another DR site, as both include another RAID controller) never happened.

SANs, or Storage Area Networks, distribute that resilience burden across many disks in its unit. Indeed, you can chain SANs to allow data storage in different geographical locations, such as a main site and Disaster Recovery (DR) site. Thereby both halving the risk of catastrophic failure and just as equally important, reducing your exposure to that risk if it should happen. Disks within a SAN are deliberately assigned to utilise no more than about 60% of the available storage space. That way, when alarms ring, you can replace the faulty disk units, whilst maintaining your resilience on the remaining space and keeping everything online. The data then propagates to the new platters and you can adjust the 60% default threshold to factor in your data growth/disk-utilisation profiles. The fact a single RAID controller took out BAU operations for what is now over 24 hours and counting shows that they didn't DR to reduce risks for this client group nor indeed, their entire client base given the ticketing system, email and client area failed so catastrophically for everyone.

To add insult to injury, at all points, Netcetera referred to this as a 'minor incident'. I asked them what this meant, as the client area and ticket failures affected every single subscriber. I was sent the reply that it only affected a small number of servers.

Granted, I am currently peeved and yesterday, that was fuel to the fire! As an enterprise solution architect, pretty much the central focus of my role is to manifest the business vision, driven by the business value, into a working, resilient, technical operation that returns an investment to the business. When you are a vendor, your business value has to be aligned to your customers value. When you make a sale or manage the account, you are aiming to deliver services in alignment with their needs. The more you satisfy, the more referrals you get, the more money you make. The closer you are to the customer's vision of value, the easier it is to do, and the more money you make.

Failure to do that means the customer doesn't get what they want or need and should rightly seek alternative arrangements from competitors who do. They can't wait around for you to get your act together. It costs them money! In my mind, for any organisation worth its salt, a catastrophic failure for everyone is a P1 issue, even if it doesn't affect the entire IT estate, given customers pay your bills. Their business value is your business' value.

Status page. Can't go 48 hours without a problem


Often technical staff do not see the effect on customers. To them it's a box or series of servers, storage units, racks and cooling. Netcetera stating that this incident was a Minor Incident, even if it looks like that from their perspective inside the box, indicates their value and the customer's value are grossly misaligned, indicating a disconnect in the value chain. This is a solution and enterprise architecture problem.

As some commentators have rightly suggested, monitors used to display service status should also aim to attach a monetary value to that status. That way it is very visible how much a company can lose when that number goes down. It is a statistical exercise to develop this utility function, but is usually a combination of distribution of errors (potentially Poisson in nature), the cost of fixing the issue including staff, parts, overheads, utilities etc. and the loss of business in that time (to their customers as well). Never mind the opportunity costs affected by reputational losses.


Netcetera SLA


As you can see from the image above, Netcetera have breached their own SLA. Compensation is limited to 1 host credit per hour up to to 100% of monthly hosting. Which isn't a lot in monetary terms. Those hosting on behalf of others may lose business customers, or suffer conversion hits and retail cash flow problems, so the Netcetera outage has a much bigger effect on them than it does on Netcetera itself and the limit of credits means that you have to use them with Netcetera alone, which for any reseller customers who host customer sites, is next to useless if they have lost much more, and are limited to a value well below your own potential loss, hence leaving you in a financial detriment position.

This is not to say that clients of theirs can't claim for loss of business if they can prove it. Most companies have to have Professional Indemnity cover for negligence or malice which causes a detrimental loss to an organisation or individual through no fault of that organisation. For those who run e-commerce sites, are resellers for other clients, or use their site as a show piece or development UAT box, this is such a scenario and you need to explore your options given your particular context. Basically, if you can prove detriment, then you can in principle put in a claim and take it further if/when they say no.

Why I used them

At the time that I joined Netcetera in 2011, I was looking for a cheap .NET hosting package. I just needed a place to put one brochureware site and Netcetera fit the bill. On the whole, they were actually quite good at the time. Tickets were (and are) still answered promptly, the have a 24/7 support service and most issues that I have sent them have been resolved within a day. So big tick there.

As time went on, my hosting needs grew a little and I needed subdomains, so given I had used them and had only raised 2 or 3 tickets since 2011, I upgraded my service in December last year. That's when all the problems seemed to start!

If Netcetera became victims of their own success, that seems like a nice problem to have. However, that also means they grew too quickly, didn't manage that transition well and introduced to much distance from executive/senior management and the people on the floor, without capable people in between. This is a change programme failure.

How should they move forward

Netcetera are in a pretty poor position. Despite their MS Gold Partner status, certainly from what I can see, it is obvious they don't attribute business value in the same way their customers do. The list of people dissatisfied with their service updates grew across all their accounts.

main company twitter feed/sales account

The Netcetera update timeline shows events as they were reported. As you can see, they grossly underestimated how long the email would take to come back online after a restore. If it was a SAN restore, this requires a propagation time as data is copied on to appropriate SAN disk units form backup and then usually disk-to-disk. This means their claim of it being available in an hour was in no way accurate! Again suggesting that the skills to manage SANs after DR were not there.

Netcetera Status twitter timeline - Highlighted email announcements. Note time difference.


The other thing that was particularly concerning is that Netcetera do not run an active-active DR strategy for their shared hosting platform. Active-active uses two platforms running concurrently in two different locations. The data is replicated to the other site, including incrementally syncing through tools such as Veem and if one site goes down, the DR site auto-switches. Active-active gives almost instantaneous failover and even with active-passive but solid syncing, this can take all of 3 minutes and some SSD based hosts can switch to DR storage, even in a remote site, in 20 seconds. This is the first alarm bell if you plan to host commercial, critical services with them. So don't!

Conclusion

Netcetera are obviously in crisis for whatever reason. Even if you are in the lucky position of being able to give Netcetera the benefit of the doubt, I wouldn't risk you or your customer's business on it. They have obviously shown that they do not share the same technical values as their customers by their classification rules and as a vendor, who relies on volumes of clients, including bigger client offerings, this is not only unforgivable from a client perspective, but really bad business!

From a technical standpoint, I'll keep reiterating one of my favourite phrase:

"Understand the concepts, because the tech won't save you!!"


******  UPDATE *******

It's now the 28th March 2014. Netcetera's system came back online at around 4am. Having tried it this morning, the daily backups they claimed are taken for DR purposes are obviously not true (or at least, yet again they have a different definition to the rest of us). Going to the File Manager only shows data from July 2013 and the SQL Server instance is actively refusing connections.

Left hand doesn't know what the right hand is doing

Exceptions this morning



It is now 47 hours since the service failed and their ability to recover from such catastrophic problems is obviously not to be trusted. I certainly won't want Netcetera anywhere near any mission critical applications I run for myself or my clients. There were gross underestimates on the length of time this was going to take to recover from. Their SLA now adds no value as we are well past the point of having 100% of the reimbursement of a month's credit  (note, by their current SLA compensation, you don't get compensated or refunded, so the PI route is one you would have to take).

What worries me is that backups are stored on the same surface as their website data. So unless you downloaded the backup, this would have failed with the rest of the Netcetera setup and you would have lost that too. This bit is your responsibility though, so I do wonder what folk would do, for those that did backups but didn't pull them off the server. Again, this is something you expect from cloud providers anyway and is what you pay for in PaaS and IaaS. It's not just about the hardware, it's about the service that goes with it (that's really the biz definition of '...as a Service'). Whilst this is of course, not what we pay for, it is an opportunity for NC to test their processes out and it is obsious they missed that altogether. So cloud on Netcetera is a definite NO!

Thursday, 13 March 2014

#NoEstimates and Uncertain Cones

It has been a good month for alienating people... if that can ever be considered a good thing. The first was outing a chap as not really knowing what he was talking about on a certain social media platform. The second was a discussion about #NoEstimates.

I am not going to go over #NoEstimates again, as you can read my initial opinion in a post from last year. The thin slicing of stories really help with this and the concepts in #NoEstimates (which are somewhat shared by ideas like the Elephant carpaccio) show a lot of promise. However, we have to remember that this in itself won't afford continual improvement. That's the missing link.

On a very recent twitter stream, I got into an argument... sorry, passionate debate, with Woody Zuill, a long time advocate of the #NoEstimates movement. One of the things I take issue with is that the term is misleading and has not just zero, but possibly damaging connotations, on the grounds that as people misunderstood agile, they'll misunderstand this term too.

I also reiterated that estimates themselves never killed projects, it was the variance between the estimate and the actual delivery effort that killed projects. That's actually rather obvious when we step out of the somewhat siloed mindset that we developers often have (and sadly criticise others for).

fig 1 - context of discussion before moving to here


If we're aiming to step up into lean and improve the rate of these tiny deliveries to the point at which they are a true flow (if, mathematically speaking we are aiming to see what happens when 'delta-t' tends to zero) and attain consistency, we need to reduce this variance around tasks (and the flow), which is the reason that #NoEstimates often works in the first place. The truth is you're always going to be delivering thin slices, not a 'zero-effort' task and as such, stats has a huge part to play in that as the variance itself increases by over-unity as the task size increases. So to summarise the agreed points, thin slices = good. Name change #NoEstimates -> #BeyondEstimates also agree.

Effing CHEEK!

*meh*

Teams don't always know the solution or even problem they're trying to solve at the beginning of a project. This introduces huge uncertainty into projects at that point. It is the point that estimates are at their most useless and are as good as guaranteed to be wrong.

As we deliver working pieces of code into production, through small increments ideally (as they naturally have a lower individual variance) then we learn more and more about the environment we're working in, the platform were working on, the problems were trying to solve and crucially, the bit that most teams miss, things about themselves and their performance in that environment.

I mentioned the cone of uncertainty in that twitter storm. The cone of uncertainty basically maps out the levels of uncertainty in projects as they move through delivery cycles. The most obvious and visible part of this is seeing the numbers of spikes reduce (or the effort required for them), as you need less and less to understand the problems that are outstanding in the domain. Granted the cone of uncertainty did exist in ye olde world, but if you follow the cone of uncertainty through the lifetime of the project, you'll very typically see the blue line, which is also matched by the funding in the diagram:

fig 2 - image from agile-in-a-nutshell (incremental funding)


Now, this is fine. You can't do much about uncertainty in itself, aside from reducing it as quickly as possible. So where I agree with Mr Zuill et al is that delivering working software often is a good thing and slicing it up thinly is also a good idea. However, this doesn't change the level of uncertainty or that developers still need to improve to deliver the value, which remember, as an investment, includes their time and remuneration (see ROI and ROR for a financial explanation of why that's the case. It's a crucial business value metric for the product owner and developers in a team who are aiming to be trusted or self-sufficient would do well to remember that. Those who have worked LS or have run their own business will already be well aware of these ).

The comment I was probably most 'insulted' by was:

...Such as delivering early and often."

At this point I wondered whether people think I am some sort of #@&!?!

I replied explaining this goes without saying. Delivering small stories early and often allows you to descend the cone of uncertainty and plateau much faster than you otherwise would, in turn getting to the point where Little's Law kicks in and you attain predictability, which is were #NoEstimates really works but the name totally misses the point of this. Which is why I agree with Zuill's assessment that it should be called #BeyondEstimates.

If you don't know where you are or what direction on that curve you're travelling (it's possible for uncertainty to increase. Ask science) then you really aren't going to make any progress. That's what I think #NoEstimates is missing.

As mentioned, the cone of uncertainty ultimately manifests in agile as an inconsistent flow and cycle time with a significant variance (statistical definition of significance). As you deliver more of these slices faster, you start to reach significance thresholds where the use of a normal distribution starts to become viable (30+ samples ideally) and you can infer statistical significance and hence provide control limits for the team. Again, #NoEstimates works well with this, as these thin slices get you to significance faster.

Flow is a concept that features extremely heavily in queuing theory. The cycle-time and throughput effectively manifest in Little's law's equation, which when applicable, can be used to answer questions like "How much effort is involved in this *thing*". However, when you start, the variance is far too high for Little's law to work effectively or return any meaningful predictive information apart from a snapshot of were you are. There is just too much chaos.

When your flow stabilises, the chaos has eradicated and the uncertainty ratio tends to get much closer to 1, i.e. the ability to track how much effort or how long each of these thin slices takes relative to the other thin slices. It's this relative comparison that then allows the predictability to manifest (lowering the standard deviation and hence variance). This makes Evolutionary Estimation easier because you have only got to think about breaking tasks down into tiny, think slices and this is where this understanding helps this evolution. Go too small, then the overhead of build->test->deploy far outweighs the development costs and in the case of ROR, monetary uncertainty increases again. 

This is something I assume everyone who knows about agile development knows about. Given his response, I am assuming that's not the case. So I am obviously in a different place from 'them' (whoever they are). However, as well as being a good talking point amongst the capable, it also seems to manifest in amateurs who just like to code, which is the same pattern I saw when I first came across XP in 2002.

History repeating itself? I really hope not! So I second Zuill's proposal to change the name to #BeyondEstimates

Signed,


Disgruntled of the web :(

Thursday, 16 January 2014

Why do we test?

In my last contract at a digital agency, I was having a discussion with a chap I worked with. He's good at TDD and we were discussing why we write tests.

The benefits of testing at developer level are well known. Writing them first and cleanly, amongst other things, provides:

  • An acceptance framework containing specifications to develop software against, using success criteria.
  • An ability to continually, reliably and consistently test against the same test case 
  • Provides developer 'documentation', in turn providing an understanding of how the system is supposed to work. 
  • Confidence that what you changed hasn't borked anything
  • When combined with automated test and reporting frameworks, they give fast feedback and a degree of progress reporting. 
One thing that came up was that we shouldn't refactor tests. I am personally dead against this idea, since this introduces extra work to change the spec if the functionality need changing. The give-away is over 100% test path coverage. That means you WILL be editing more tests than you should do, which is just wasted time and effort. Note though, if it's a choice of 150% tests or 90% tests, I would choose 150% every time.

However, one thing that wasn't brought up, which I personally think is equally important, especially if the project is high value, high risk or highly sensitivity, is governance.

Ewww... Management speak.

Yes, basically it is.

We have to remember that being agile involves being multi-skilled. Part of that is managing risk and whilst tests give you some degree of that, the test coverage gives you the governance of the code and development that you need. If you have 10% coverage in your project, people have not been doing TDD now have they?

Self-sufficient agile development teams are able to govern the development of the system. Some might think governance is used because you don't trust the developers, but really, it's just as much about managing the risks with the code and gaining the biggest bang for the developer buck (effort). As a team of developers, in order to become self-sufficient, we have to be able to govern the development of the software and by proxy, the team. 

QAs and BAs have a pivotal role in this process. They know the real business value in the system and as such, they can guide where to put the testing effort. Developers can also get a sense of the importance of the code because they'll have touched specific code more than once. 

Cyclomatic complexity can also be key to all this, since the greater the cyclomatic complexity, the greater the number of tests required. If the cyclomatic complexity is high, the number of tests is high simply because of the combinatorial nature of the tests required to cover this cyclomatic complexity metric.

For example, we are human beings and we are not faultless. Anyone who claims otherwise is deluded. So if you have a piece of code which is touched by several developers, or even the same developers multiple times, it is more likely to contain bugs over time than a piece of code written the same way once and not touched since. The purpose of the tests, amongst other things, is to make sure you don't break anything when the next person touches it or you next touch it. It gives you the confidence to refactor it too. Without automated tests, and the quick feedback it brings, refactoring becomes a nightmare. After all, logical bugs don't go through the automated test sections of the covered code, they fall through the holes where the code isn't (whether due to the lack of acceptance criteria or missed path coverage).

Q: Isn't cyclomatic complexity useless?

Nope. I do often wonder why people say that. The explanations I keep seeing or hearing show they actually understand none of it. You also get criticism from developers that QAs insist on a metric such as cyclmatic complexity less than 10 and we end up coding too much 'crap'. However, let's look at why we have it.

Let's use a variation of the one shown on the MSDN website. This code is deliberately rubbish, without full statement coverage but could still be created using TDD (characterisation tests first) and before refactoring anything.

Using FxCop, dotCover and the Code Analysis Powertools in VS2010, you can analyse the solution and get the following:

dotCover statement coverage and the FxCop equivalent code metrics.

The key metric we're focussing on is the cyclomatic complexity (CC) of the method named 'Method'. This is high for the method, but what does this actually mean?

Well, the path test coverage on this would require the developer to write a test for each of those cyclomatic paths through the system. In this case, 15 of them. Filling in the rest as proof:


dotCover and FxCop analysis of code

Now, the interesting thing is we have 16 tests for a cyclomatic complexity of 16. Let's understand what this means:

  • There are only 10 lines of code in one method, and we have had to write 16 test for it - In itself, not a problem
  • We can see some clear areas for refactoring. Again, a good thing (see below as I go through it)
However, let's compare this with a wrapper  if statement (which tests for whether you care or not), then we can see we have to change more code than we otherwise would have to and this costs the business more.

I've refactored it to use a surrounding 'if' wrapper. The tests still pass, but the cyclomatic complexity has reduced to 9.

dotCOver and FxCop analysis after refactor
However, we still have 15 tests. So our coverage now sits at about 167%. That is 67 percentage points more code that another developer (or even ourselves) would have to change if we needed to change the class to do something. This is also only one level of nesting. Adding this method to another method as full, which is covered 166%  means the total combinatorial effect means we have 276% coverage. If the combined TDD development time of a module is 5 days at say, 3:2 dev to test during the TDD iterations, then the tests should only account for about 0.72 of a day and development taking the same amount of time (3 days), the other 1.28 days is just sheer waste. That's 26% of the development time.

Scale this (best case) to each time a block of code changes and suddenly, if the code is changed 10 times across stories in an iteration, you suddenly have 12.8 days that just disappeared out of a 50 day project! That's a lot of effort, time and money wasted. Development teams should respect the people that trust them to deliver, who also pay their wages.

The following is the NUnit TestFixture:

using NUnit.Framework;
 
namespace WhatCanIDo.Test
{
    [TestFixture]
    public class DayOfTheWeekTest
    {
        [Test]
        public void WhenItsMondayAndYouCareThenSayItsMonday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Monday, true), Is.EqualTo("Today is Monday!"));
        }
 
        [Test]
        public void WhenItsMondayAndIDontCareThenSayYouDontCare()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Monday, false), Is.EqualTo("You don't care!"));
        }
 
        [Test]
        public void WhenItsTuesdayAndYouCareThenSayItsTuesday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Tuesday, true), Is.EqualTo("Today is Tuesday!"));
        }
 
        [Test]
        public void WhenItsTuesdayAndIDontCareThenSayYouDontCare()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Tuesday, false), Is.EqualTo("You don't care!"));
        }
 
        [Test]
        public void WhenItsWednesdayAndYouCareThenSayItsWednesday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Wednesday, true), Is.EqualTo("Today is Wednesday!"));
        }
 
        [Test]
        public void WhenItsWednesdayAndIDontCareThenSayYouDontCare()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Wednesday, false), Is.EqualTo("You don't care!"));
        }
 
        [Test]
        public void WhenItsThursdayAndYouCareThenSayItsThursday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Thursday, true), Is.EqualTo("Today is Thursday!"));
        }
 
        [Test]
        public void WhenItsThursdayAndIDontCareThenSayYouDontCare()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Thursday, false), Is.EqualTo("You don't care!"));
        }
 
        [Test]
        public void WhenItsFridayAndYouCareThenSayItsFriday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Friday, true), Is.EqualTo("Today is Friday!"));
        }
 
        [Test]
        public void WhenItsFridayAndIDontCareThenSayYouDontCare()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Friday, false), Is.EqualTo("You don't care!"));
        }
 
        [Test]
        public void WhenItsSaturdayAndYouCareThenSayItsSaturday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Saturday, true), Is.EqualTo("Today is Saturday!"));
        }
 
        [Test]
        public void WhenItsSaturdayAndIDontCareThenSayYouDontCare()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Saturday, false), Is.EqualTo("You don't care!"));
        }
 
        [Test]
        public void WhenItsSundayAndYouCareThenSayItsSunday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Sunday, true), Is.EqualTo("Today is Sunday!"));
        }
 
        [Test]
        public void WhenItsSundayAndIDontCareThenSayYouDontCare()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Sunday, false), Is.EqualTo("You don't care!"));
        }
 
        [Test]
        public void WhenItsDunnoDayAndIDontCareThenSayYouDontCare()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.DunnoDay, false), Is.EqualTo("You don't care!"));
        }
    }
}

You can see that as we went along, we 'coded' the tests for each of the "don't care what day it is" scenarios right into the code. The excess ones now are not needed at all, since whatever we do, the don't care is actually decided separately from each check on the day. So these can be removed, which will remove 7 test cases.


Important Notes
If you do refactor tests, and I personally think you should, then:

  1. NEVER refactor tests if the code is red! 
  2. Use the tests to green the code and the code to green the tests but never change both at once!
Removing the 7 extraneous tests then makes the test class look like:


    [TestFixture]
    public class DayOfTheWeekTest
    {
        [Test]
        public void WhenItsMondayAndYouCareThenSayItsMonday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Monday, true), Is.EqualTo("Today is Monday!"));
        }
 
        [Test]
        public void WhenItsTuesdayAndYouCareThenSayItsTuesday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Tuesday, true), Is.EqualTo("Today is Tuesday!"));
        }
 
        [Test]
        public void WhenItsWednesdayAndYouCareThenSayItsWednesday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Wednesday, true), Is.EqualTo("Today is Wednesday!"));
        }
 
 
        [Test]
        public void WhenItsThursdayAndYouCareThenSayItsThursday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Thursday, true), Is.EqualTo("Today is Thursday!"));
        }
 
 
        [Test]
        public void WhenItsFridayAndYouCareThenSayItsFriday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Friday, true), Is.EqualTo("Today is Friday!"));
        }
 
        [Test]
        public void WhenItsSaturdayAndYouCareThenSayItsSaturday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Saturday, true), Is.EqualTo("Today is Saturday!"));
        }
 
        [Test]
        public void WhenItsSundayAndYouCareThenSayItsSunday()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.Sunday, true), Is.EqualTo("Today is Sunday!"));
        }
 
        [Test]
        public void WhenItsDunnoDayAndIDontCareThenSayYouDontCare()
        {
            Assert.That(DayOfWeekConverter.Method(DayOfWeek.DunnoDay, false), Is.EqualTo("You don't care!"));
        } 

    } 

gives us 8 remaining tests and sure enough:

dotCover results after removal of 7 extraneous tests

Summary

In short, cyclomatic complexity is a brilliant metric for governing how many tests are needed in your solution. There are two main useful comparisons in isolation and teams should take heed:
  • If cyclomatic complexity is greater than the number of tests, then you're missing test scenarios and risk introducing bugs into the system. If there is a hole in a bucket, Henry can't carry as much water. Most Agilists should aim to get here as a bare minimum in today's industry.
  • If the cyclomatic complexity of a method is less than the number of unit tests around it, then you have over 100% coverage and you introduce waste into your process. This comes when you step agile up to the lean plate!
So to be lean, 100% should be the norm. Anything else is suboptimal or worse.

Tuesday, 17 December 2013

Lean Non-Profits?!

In a slight departure from my usual blog content, I am going to look at an application of lean start-up techniques to the rarely considered third sector. I must warn you, whist I try to only use the bare minimum, I make heavy use of statistics and without an understanding of that, you may find that part pretty hard to follow.

I am assuming you know enough about Lean Startup to follow the process through and identify the key concepts. Also, this is a 'change programme', as all lean processes technically are.

My Volunteering Side

Those that know me well are aware that as well as a hectic working life, I also typically have a voluntary sideline which takes upwards of 20 extra hours a week out of my spare time. I like to joke that it is my 'b**t**d offset', so I can be as nasty as I like about development practices without incurring the wrath of my conscience. Although it is on my CV, I don't tell many people that, since it doesn't exactly do much for my 'street cred' ;-)

You?

A bit of background. For 6 years and 8 month I was an active trustee on the board of a Citizens Advice Bureau office. My UK audience will know this as probably the UK's biggest walk-in advice brand and provides all manner of help to individuals, couples, families, business and vulnerable people.

Topics range from consumer advice, finance and debt advice, welfare benefits and workplace conflict through to patient support and advocacy in primary care organisations, utility bill support and sometimes tribunal representation.

What UK residents often don't know, is that Citizen's Advice is a federated charity organisation which is completely independent from public or private sector affiliation. Back in 2011, it was made up of 432 bureau, each of which is a separate, individual charity in its own right, with a membership commitment to central Citizens Advice. Each is usually set up as a company limited by guarantee (Just like every UK limited company, reporting to Company's House) and an official charity with a registration number (registered with the Charity Commission). So there are not one but two sets of trustee and directors reports to submit and the accounts have to be submitted twice. Once as per the usual limited company requirement and the other typically using SORP.

On top of all this, being members of a federated, membership organisation, just like a franchise, brings with it audit requirements on quality of service and brand promotion. Plus, we have to still maintain the usual standards of health and safety, manage staff according to employment regulations, health and safety, dignity at work, equality and diversity etc.

We also have to look at developing the service, staff and volunteers, reviewing policy documents, promoting the service, business strategy, locating sources of funding and development strategies, both internal and external to the 20 person office. So as you can see, there is a significant amount of regulatory and compliance work, much more than a standard limited company and that is often appreciated by one or two man consultancies and contractors. Plus, we take on the risk of trustee liability, meaning that any negligent activity on behalf of the trustees which cannot be covered on insurance means that despite the limited company status, we could be chased for any liability. Finally, the crust on top is we do this and endure this risk for absolutely no pay at all. Horror stories of trustees losing their homes through joint liability when something has gone wrong can be particularly scary. If that isn't truly doing it for the cause, I don't know what is :-)

My role, as well as the role of others on the board, was to decide on bureau direction and then steer the bureau through what in late 2007 and early 2008 became uncertain and unprecedented economic times.

What Was The Problem?

In early 2010 we got invited to a trustee conference. I and the chair went along and there was a presentation from Mike Dixon, where he outlined local authority funding cuts that had hit a lot of bureau and also that 80% of the cuts to funding were yet to come. We were all aware of it and some of us were even aware of the scale of further cuts that were coming.

We knew by that point that the loss of major contracts and grants was a huge blow to some of the 432 organisations. Some had been closed or had to merge with nearby bureau. Central Manchester CAB in particular had merged with two fellow network organisations and had seen a cut in it's revenue stream of £1.5 million. 33% of it's total revenue.

Our much smaller bureau was not that big at all and our total revenue stream was half what central Manchester had lost. If we only had a single contract and lost that value, then given the outgoings in both overheads and staff salaries (yes, some charities pay trained staff for specialist skills) we'd have had no option but to close. Being aware that further, substantial local authority funding cuts were coming meant that we also had to take a good, honest, internal look at our service and streamline where necessary.

How Was It Solved?

In 2011 we kicked off the new year by starting a change programme to look at the efficiency of the service as well as investigate how we could de-risk our current operations and explore other sources of grant and contract funding, which for us, was less traditional. We involved everyone in the organisation, top to bottom in this activity and out of that, we conducted many smaller tasks and developed a measured baseline of the company (putting my enterprise architecture hat on, this is effectively a baseline architecture) and hence, a number of elements we could look at.

In mid-2012, we conducted a culture review, asking how staff felt the organisation was. As part of the programme of operational review, we looked at the usual change factors of culture, people and processes.

We made a point of asking directly, since there had been concerns about the trustees not seeing the operations on the ground floor and only seeing what Lean Startup calls 'vanity metrics' through the reports of the chief executive. When we started to measure our personnel's view of the organisation directly, it became apparent that people weren't actually happy and some staff were even stressed, due to unfair targets set by the contracting authorities which we had to meet.

We started a change programme which I headed up. Now, I have run many a change programme in my time in the IT sphere. Indeed, if you are running a truly lean organisation, you should always be changing. In a non-IT sphere, this was comparatively new. I was very aware of the Lean Startup method and thought that there wasn't any reason not to apply it here. Indeed, given we had a baseline of the organisation through our culture review, we had what was effectively our 'B' scenario. So in true LS style, the process went:

  • Find a problem
  • Form a hypothesis
  • A/B-test
  • Evaluate and Pivot if applicable

I'll focus on one of the problems that was solved through the applicaiton of LS, but we did this a few times in all of people (roles and responsibilities), process and culture.

Can you Run LS in Not-For-Profit Companies?

I can categorically say Yes!

The main difference in using LS in a not-for-profit organisation is that your aim isn't simply to work lean to make money. You balance a number of forces which pull you in different directions, including conducting trade-off analyses on benefiting individual service versus supporting the good of the service and by proxy, wider service users; Staff and volunteer needs versus organisational and service user needs; Internal needs versus KPIs; Processes versus human morale; Availability versus efficiency; Waste versus service promotion etc. etc.

However, you'll notice that this is the classic uncertain environment in which Lean Startup thrives. In solving this, I nurtured LS across the programme by slowly using LS to introduce LS itself into operations, through different but receptive members of the organisation, who themselves became part of 'A' and 'B' teams. With an understanding of the questionnaire results and with a nod to Maslow's Hierarchy, I presented the reasons for the change to each change advocate in a way I hoped they would be receptive to and it was the analysis of the number that showed me where to focus.


I'm Not A Number, I'm a Human Being!

People have measurable characteristics assigned, such as height, weight, age etc. and this was actually more an opportunity for the individuals to allocate measurable characteristics to us as an organisation. How much they felt part of the team? How well they felt the organisation was respected? Did they enjoy their job?

As it happens, this is the bit I relished. I get told by non-experts that you can't quantify humans in numbers, which is true and that's not what I sought to do. There are many things you can get from people, especially in the form of questionnaires, using what statisticians call multivariate analysis. You are not going to get a perfect answer, but what you are looking for in cultural analysis, is trends in the organisation which present as 'clusters' around particular areas.

The questionnaires asked staff to rate out of 10 a number of factors across the organisation. The questionnaire composed 66 questions in following 16 high-level groupings.
  1. Working Environment
  2. Health and Safety 
  3. Satisfaction at Work
  4. Clarity of Roles and Responsibilities
  5. Environmental Sustainability
  6. Equality and Diversity
  7. Quality of Service
  8. Immediate Management and Supervision
  9. Peer and Organisational Support
  10. Change Management
  11. Workload and Bureaucracy 
  12. Work Related Stress
  13. Intra-organisational Communication
  14. Self-Involvement
  15. Retaining Staff
  16. Dignity at Work
This questionnaire was our cultural baseline. A measure of the health of the organisation from the people's perspective. 

Once the questionnaires were in, the next step was to identify key, root factors from the analysis which formed high level themes. This is where the correlation matrix came in.

A Coral... What?

A correlation matrix is used in factor analysis to find high level factors which seem linked and give you a place to look. It is simply a matrix plot of all Pearson correlations between the distribution of the scale answer of one question against the others. Note, as the saying goes, "correlation is not causation" and as such each individual link doesn't give you an absolute decision, but something you can use to find out if there is a decision that needs to be made. The more factors that lean in a particular direction, the more the variables are linked and as such, the more the correlation hints at some causality. It's a zero knowledge game.

For example, one of the questions we had was:

"Do you feel your satisfaction at work is generally high?" 

This was correlated 85% with the question

"Do you feel you have an appropriate level of control over how you carry out your work?"

This is a good correlation. Anything over 70% is regarded as strong and should be considered a candidate factor. 

We also made a point of asking variants of questions, so that we could account for some confounding variables in interpreting questions. For example:

"Do you feel you have an appropriate level of control over how you carry out your work?"

Was repeated with the variant:

"Do you have enough autonomy in your work?"

Autonomy and control are not the same thing, but the purpose of this question was to determine if people answered one question by considering the other and thus, accounts for it in the correlation matrix, since we can compare the two correlations and we'd hope they would be similar.

In the end, the correlation matrix looked as follows. Don't worry too much about not being able to read the text, the key is the clustering of the red and brown colours. The pink colours are simply blanks, as they don't give us correlations strong enough to want to trace. As a general rule, the absolute thresholds (positive or negative) should always be:

Less than 50% - Weak correlation. Ignore it

50% <= Correlation  < 70% - Moderate correlation. Only really useful in a supporting capacity or if a number of factors have similar correlations.

Greater than 70% - Strong correlation. Follow this up!!

fig 1 - Correlation matrix of  organisational culture review 

These rows and columns are grouped by area of investigation. Red shows strong correlations, dark orange/brown shows moderate correlations. What was interesting is the clustering in certain groups of questions, which mean that the questions were regarded as related and may even have been the same factor in the minds of personnel.

How Do You Find Anything in That?

The next step for us was to conduct a factor analysis, to find the main themes that came out of the review.

The purpose of a factor analysis is to look at the distribution of all the above statistics, by forming conjectures around the independent variables in the distribution and identifying a set of coefficients which match the distribution as closely as possible. If you can't make it match, then the independent variables are wrong. Pick others. The problem, as the question that begins this section implies, is trying to find a set of factors to form that basis.

Luckily, the more questions you have, the easier it gets. The factors typically show up as very related 'clusters' in analyses such as the above, when the questionnaire is well designed. For example, pay and conditions in the above list is the biggest 'block' on the grid, and in the end, when accounting for other correlations elsewhere, we found that this really represented one factor.

We found several themes that came out of the analysis. Namely (in no particular order);

  • Staff Workload
  • Supporting Personnel
  • Managing Performance & Change
  • Staff Identity
  • Employer Responsibility
  • Bureau Image  
  • Corporate Social Responsibility

When the changes then started, they addressed one or more of these themes. Anything not satisfying an organisational need present in the theme was ignored, since it didn't contribute to the value of the service.

This task was eventually automated so that the health of the organisation could be obtained by simply assessing people again. We looked to introduce a Survey Monkey survey into the company to get the raw data, but the uptake of this wasn't high. People seemed to prefer paper and given it wasn't directly adding business value, we dumped the idea and focussed on the paper questionnaire, but seting up a template Excel sheet for the analysis.

Not too Lean so far!

True. Less the 'startup' as well. However, we were running our existing organisation and we were looking to improve our efficiency through improving morale and engagement, facilitating staff's preferred roles and building their identity. We already had our 'B' scenario in what were driving and as mentioned, we ran the 'A' scenario in parallel with this traditional 'B' scenario.

Note, in a commercial organisation, the aim is to improve financial metrics. For this part of the change programme, the aim was to improve staff morale, efficiency and thus, service provision. After inviting staff to participate in interviews to corroborate the strong correlation (in red in the above matrix), we found one of the factors in low staff morale was that that staff preferred helping service users instead of reporting on progress. They felt that since the introduction of targets by the contracting authority to justify our existence, it has made their lives very difficult.

On further investigation, we found that the reporting process was hugely wasteful. Every quarter, for our management meetings, staff were required to report progress against each location to their operations manager, who would then filter and report that to the chief executive who would then filter and report that to us on the board. We had all the reports from the staff in our pack and our board pack would take the best part of a day to read for each of the 7 board members. The pack was huge, the quality of the strategic information was low and repetitive and it wasted lot of paper and time all round.

Additionally, the filtering process meant that all staff had to deliver their reports to the operations managers no later than 10 days after the end of the quarter, reporting statistics from the system which is processed manually. The statistics gathering process took 10 man-hours to process them due to a lack of Excel skills in-house and all in all, each individual member had to find 13 hours of time for their reports, whilst simultaneously maintaining the contracted 50% face-to-face contact time with service users. Every quarter, this hit part-time staff much more than full-time staff and this led to a massive hit in morale amongst that group, which then spread, given a correlated reliance on peer-support over management and supervisor support found in the correlation matrix, especially in satellite offices.

Also, operations managers never got to manage internal and external operations effectively, since they spent a lot of time dealing with filtering reports and reporting progress on metrics which rarely change (for example, who was employed doing what in which project). This had a knock on effect on the chief executive, who could never look outside the bureau for sources of funding whilst looking inside the bureau at staffing and management issues.

After a bit of analysis, this became my first target for a change in process.

fig 2 - Leaner Reports Hypothesis  

The hypothesis became:

"If we streamline and automate the reporting process, we'd give staff more time back to face-to-face activities which they enjoy most"

By our calculations, if we decoupled the reporting filter chain and automating the production of statistics, we'd give all staff, trustees and volunteers an average of 10 hours back a quarter. For part-time staff that is half a week's work. Graphs would improve the communication of information and when combined with historical automatic information would allow us to find trends to take action faster.

So here's the LS?

Yep.  I drafted the help of one of the two operations managers for this task. I introduced LS to them, explained the role of A/B-testing in that and asked them to choose some members to form the 'A-team' and ask them to produce less narrative and the operations manager was to produce no duplication of information contained in the reports. I also wanted them to produce static information about the contracts they delivered, their contract end dates, value and responsible staff members. I also wanted them to inform the A-team to keep quiet that they had the 20 extra days in the month to produce that new version of the report. I would not be automating the report in this first pass.

I then asked them to time how long the reports took to write and for us, to read. This new method was then run for that quarter. The results were written up and presented to the board. The numbers were very very good.

Improvements
Word Count Down 35%
Narrative Writing Time Down 33%
Board Reading Time Down 87%
Staff Reporting Window Up 211%
Operations Management Report Window Up 403%
Bureau Management Reporting Window Up 300%

We decided to pivot on this and this new reporting process was then rolled out across the rest of the team, including through the second operational line. 

Next...

In addition to this, I went on to introduce the automated statistics generation process. I also included a screen-cast of the new automated process and attempted to encourage staff to peer-train, since they already had strong peers support shown in the culture review analysis. This is effectively akin to pair programming, or triple programming to be exact. An experienced member of staff oversaw lesser experienced staff who led the training of the least experienced staff member in performing live tasks. That maintained the QC loop as well as solidified the intermediate level member's skills and mentored them and introduced the staff member to the system and their colleagues. The least experienced staff member would then become the intermediate member for the next iteration, with the the current intermediate member becoming the most experienced. When new changes were made to the organisation, this would be repeated  ad infinitum.

The programme had many other facets that were being addressed before I had to retire. This included reorganising the bureau structure through the introduction of 'deputy' roles. Moving administration into cross cutting supporting functions. 

In Summary, What Did You Learn?

You may not believe this, but I kept the article very very short. There was a whole manner of analyses and lessons that went into this set of metrics. There was a lot of the usual change management and control elements that we still had to go through, especially in the early, transitional stages. 

Plus, in order to make this work, we had to make changes at all levels across the three typical domains of change, People, Process and Organisation. This included plans for the organisational structure of the bureau, greater management assistance, empowerment and motivation for managers and staff and even moving into new, flexible, bigger offices, changing the IT landscape to support remote working (especially for outreach sites and to mitigate issues around weather, traffic, childcare etc).

We changed policies at trustee level (i.e. changing governance documents at the level of trustees). We also attached SMART objectives to every person's role and appraised them on it. Which defined specific acceptance criteria, but crucially, they were very simple statements of what had to be done, but not how. There was no dictate as to how it would be done. The way it was done was at the whim of the individual. This wasn't to say KPI's couldn't be measured, just that it had to be achieved with an efficient investment of resources and an awareness of the trade-offs that came with them.

We also had to try to set up a culture where this was encouraged and rewarded. Unfortunately, we were in a place were stress and perceived job insecurity due to the funding cuts meant this wasn't easy. However, eventually, the necessary changes were made.

fig 3 - Snippet from change programme introduction

fig 4 - Change programe elements, which included Lean Startup elements

To start with, it was all driven by us, since an immediate switch from the hierarchical, static structure we previously had was not going to would cause everyone to revert to type. Things won't change overnight and personnel, being human beings, don't regularly like change. It destroys the comfort zones they build up and for some, is a direct attack on their identity. So you have to be somewhat sensitive to those concerns all the way through the process. It doesn't just change the company, it can very definitely change the people within it.

If I had to put together my top 6 tips that helped institute LS, they would be:
  1. Be mindful of natural forces - As with traditional management techniques, be aware of the needs of your staff as human beings and play to their natural 'pull'. It lowers resistance to change and friction as well as maintain and maybe even enhance morale. 
  2. Reward success and learn from failure - Even if you fail at something you've till succeeded at learned that in that space, place and time it doesn't work. I would even go so far as to suggest you remove the word 'failure' from the vocabulary of the workplace. That requires a defined and certain yardstick, which by the principle tenet of LS you don't have (uncertain environments mean moving goalposts).
  3. Empower individuals - Empower and encourage every personnel member to take ownership and make things happen in their sphere.
  4. Foster LS from the ground up - Get individuals involved in the experimentation process and do not leave this as a management concern. Get them to figure out better ways of getting their jobs done. After all, they do this every day. Be aware that you really have to sell it to some people, especially those steeped in traditional management and leadership techniques. Some people can simply be motivated by seeing it working.
  5. Encourage communication - For us, that meant all of the management team were required to keep an open door during the change programme. Encourage staff to come and discuss their concerns and bring their suggestions. That way the leadership know what is going on and the staff members get to understand the rationale behind decisions.
  6. Don't expect step changes overnight - As with all change programmes, there are some elements that can be changed quickly by dictate. If your organisation already is dictating processes, then the last dictate you should ever make is that your staff learn about LS. Slowly migrate and institute LS into your organisation bit-by-bit, after all, like it or not, your organisation is a system too and making small incremental changes to it is the best way to check if it is improving.
Although I have left out a lot of detail, I can definitely say that Lean Startup can be used in charitable organisations. It's a time when this has to be a serious consideration for small and larger not-for-profit organisations alike, as well as the traditional market of entrepreneurial startups, teams and enterprises. I hope this helps encourage others to adopt LS in their organisation, never stop learning and if you try it, I wish you the very best of luck!