Executives and Top-Down Transformations

An obvious place where Executives and Agile Beliefs diverge is when it comes to Agile Transformations. Executives tend to favour top down big bang implementations whereas Agile Practitioners prefer bottom up safe to fail experiments.

Screen Shot 2017-04-15 at 10.55.47.png

This is not really the executive’s fault as they are driven by the need for fast results. Executives generally have a tenure of five to ten years. This is a surprisingly short period of time to effect significant lasting change in any established, traditional organisation.

The difference between traditional methods and Agile is that traditional methods tell you how to write software. Agile methods do not. As Tony Grout says “Agile methods are the simplest practice that will tell you the problem you need to solve“. Whereas traditional methods force the team to mold around the practice, Agile molds practices around the team and the context that they operate in. In other words, one size DOES NOT fit all. It takes time for a team to develop a stable and effective method for their context. It is not simply a case of the teams learning a new method, its a case of the team using Agile practices to create their method.

The change is bigger than just the development teams

screen-shot-2016-12-03-at-06-46-57

Its not just the teams. The program management structure that manages the risks of the cross team development needs to be developed using Agile techniques. Whether you adopt Flow, LESS, Nexus, SAFE or DAD, its not just a process. All of the people operating the system need to learn a new way of working, and even harder, a new way of behaving. People need to learn how to learn “work with” rather than “work for”.

At the portfolio level, the organisation needs to bring all the business heads together in order to agree on the organisation’s backlog. This allows engineering to start managing its skill liquidity using a tornado graph to support investment and divestment of capacity. The organisation can become a team of teams and focus on its customers and it external competition rather than focus all of its energy on internal rivalries.

Screen Shot 2017-04-15 at 14.17.04.png

And this brings an uncomfortable truth and realisation to the CEO and Chief People Officer. Getting a business executive to give up their goals in order to help a fellow executive achieve theirs for the greater good of the company means that the (executive) reward system needs to be upgraded. An upgrade to reward collaboration and reward focusing on the goals of the overall organisation rather than sub-optimal local goals. It will take the HR function a number of attempts before they find the right path to a new successful reward system.

The organisation will need to implement a risk management system that allows business leaders and IT leaders to collaborate on managing the risks associated with investments involving IT. Not just copying a blog post but training audit and assurance functions in how to tell the difference between a well run project and one that presents a serious risk to the organisation.

The simple matter of funding becomes a issue at some point, though later than most think. Although the finance department needs to build a new way of funding projects, a more urgent imperative is to find a better way assessing the value that investments in IT deliver.

As well as learning to collaborate as a team, the executives need to learn how to create safe to fail cultures that promote learning. Executives need to learn an entirely new set of skills and behaviours. They need to learn how to create a new culture and tools for changing culture such as story telling and walking to talk. They need to learn how to see culture, the culture they need and the culture they need to move away from.

But before anything can start they need to build trust and respect with their fellow executives. Not something that happens over night.

And they need to do this fast, during their short tenure of five to ten years. No wonder they prefer big up front design, top-down transformations run by consultants who can be blamed for failure.

Starting an Agile Transformation Fast the obvious way

Doing it fast is easy. You select a method…. LESS, NEXUS, SAFE or DAD and simply roll it out. You hand out copies of the relevant book. You hire clever consultants and coaches, and you hire trainers to roll out standard training.

That “works” if you assume that an Agile transformation is “obvious” in Cynefin terms.

You will start fast and fail even faster, though perhaps only after you have spent a lot of money on consultants and coaches and training.

The upside for this strategy is that your bosses will perceive that you are a “get it done” individual who is making a difference. You will have a big up front design for your transformation. A big plan from a big name consultancy to get to success.

In the words of Helmuth von Moltke the Elder

“No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength” (or “no plan survives contact with the enemy”) and “Strategy is a system of expedients”.

Starting an Agile Transformation Fast the complicated way

Instead you may consider that an Agile transformation is “complicated” in Cynefin terms and seek “experts” or get a big name consultancy to undertake an extensive analysis.

  • If you are unlucky, you will encounter consultants who will show you powerpoint slides with lots and lots of detail of successful transformations at similar organisations, a brightly painted roadmap, and a standard process that involves time boxed analysis or capability assessments. They will have an army of graduates and cheap developers micro-managed by “get it done” leaders to help you transform.
  • If you are lucky, you will hire one of the small handful of people in the world who have real experience of creating genuine Agile transformational change… And they will tell you that an Agile transformation sits on the boundary of “complex” and “chaos” in Cynefin terms, with large elements of “obvious” and “complicated”. P.S. If you are wondering which stone to look under to find these people, you could do worse than start here.

You will learn the goal or destination in an Agile transformation is “complicated” which only an expert or analysis can tell you. Big name consultancies are good at providing a business case and delivery plan to help you secure funding and “commitment”. They will provide a nice “complicated” powerpoint diagram showing all of the elements of the new organisation. It will be a beautiful diagram with an even more beautiful story told by beautiful expert story tellers in beautiful suits with beautiful hair. It wont work of course, but it will be beautiful.

The good news about assuming the transformation is “complicated” is that if it doesn’t work, you can always blame the experts and their beautiful diagrams. This is a particularly popular strategy in risk averse cultures.

Finishing an Agile Transformation Fast the Complex / Chaos Way

Although the goal is “complicated” the transition from where you are now to where you want to be sits firmly on the border between “Complex” and “Complicated”. Although everyone might agree that the destination is Paris, the path you take will be different dependent on whether you are in Versaille, or London, or Tokyo, or Cape Town, or Athens, or Olympia, or more likely Olympus Mons.

Experienced agile practitioners will tell you that tales of success are inspiring but you need to dig beneath the polish and look at the failures. Success is more likely if you avoid the failures rather than try to emulate the success.

Screen Shot 2017-04-15 at 14.27.17.png

You will need to set up a portfolio of “safe to fail” experiments. Experiments that tell you the best place to apply LESS, the best places to try SAFE and DAD and Nexus. The best places to organise using the Spotify Model and the best to organise using the Buurtzorg Model. In order to make the experiments “safe to fail” you will need to speak to people with real experience of applying these approaches so that you can learn about the known failures. You won’t find out about failures from a sales brochure or a shiny powerpoint. You find out about them from people who trust you.

Executives attempting an Agile Transformation need to build a lot of trust and that takes time. It takes time to build trust with the Business Heads, and the CFO, and the CRO, and the CPeopleO, and the COO… Especially as the CIO is often not considered important enough to be on the board of non technology companies, often reporting to the CFO or COO.

When instigating a Lean Transformation Students of Taiichi Onho would insist on the board, lead by the CEO making a significant change to the production line. Taiichi Onho’s students would lead them from the boardroom and make them publicly dismantle a key part of the production line. If they were not prepared to do that, Taiichi Ohno taught them to walk away as they were not ready. If an organisation is embarking on an Agile/Lean Transformation, the first act of the board should be to appoint the CIO to the board (if they are not already on it). The second act should be for the board to go to the place where the transformation will start and dismantle the desks and dark cubicles with screw drivers and allen keys and , and replace them with collaborative spaces. The board should collaborate with the teams to create the Kanban boards that they want to see when they “Go the Gemba” to sit with the teams so that they can remove impediments and blockers for the teams. If the board are not prepared to do these things, they should abandon the transformation before they start.

The board need to understand that the transformation is not the destination. They need to understand that the transformation is the journey. They need to nourish and protect their experiments, removing impediments and blockers for them. At Agile2007 in Washington D.C. one of the participants stated that “Agile is a commitment to personal growth and learning as well as a company’s commitment to growth and learning.” The board need to make their trailblazers feel safe on their learning journey and shape a culture that supports growth and learning. The board need to be involved and make sure that improvements are happening. The board needs to ensure that value is delivered along the journey and not just at the end. A constant movement towards a better organisation.

A tale of two approaches

The Agile approach to transformations is to start small and gradually grow the size of your “safe to fail” experiments as you succeed. Start small and build your knowledge. Grow your people and get them to engage with the Agile community outside of your company. As you build your knowledge, build your infrastructure and risk management systems to support the new way of working. The key to success is growing the knowledge and experience of your existing people so that its your own people who do the scaling and not external consultants.

The executive approach is to hire a big name consultancy, create a top-down big up front design of the organisation and implement it in a big bang approach. Of course the bang normally comes just after the consultants have taken their fee. It is normally driven out of IT as an IT initiative without the need for proper engagement with the business. The IT executives do not need to learn anything new as they are doing it to their organisation rather than with the organisation. The good news about this approach is that the experts or consultants can be blamed when it fails.

Perhaps if CEOs were given the proper amount of time to roll out a transformation and given the proper support of their colleagues on the board (assuming they are on the board), they might try a more sensible approach.

Advertisements

Executives and Courage

A key value of both Scrum and Extreme Programming is courage. Both methodologies are based on the idea that team members create a system that allows them to act with courage.

Screen Shot 2017-04-09 at 14.30.07

Scrum says…

“Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.”
Extreme Programming says…
“We don’t fear anything because no one ever works alone.”
Agile believes that team members can act with courage because they act as a team where everyone supports each other and no one is allowed to fail as an individual. Executive teams by comparison are assigned clear accountability and responsibility for certain operation aspects. This accountability is so baked into the executive culture that it is reflected in their job titles. Chief Financial Officer, Chief Operational Officer, Chief Information Officer, Chief People Officer. Yet these roles interact. Operation fails because the technology is lacking. The technology is lacking because there is inadequate investment funding. Investment Funding is inadequate because spending on Operations is too high. They operate an inter-connected system by trying to optimise their own sub system. Even worse, they are often competing with each other in a zero sum game bonus and promotion culture. This lack of team work and safety at the executive level leads executives to lack courage and they engage in risk averse behaviour that permeates the culture of their organisations.
To understand risk aversion, lets look at the behaviour of investors. Risk appetite is a well studied and understood aspect of finance. In finance, there are three categories of risk appetite:
  1. Risk Averse – The risk averse want to avoid or ignore risk. Their main strategy is to get an expert to manage the risk for them.
  2. Risk Neutral – The risk neutral are flat risk, they buy and sell and aim to keep their position flat or neutral. They often act as intermediaries in deals or use their superior expertise to break complicated problems into simple ones.
  3. Risk Takers – These people seek to understand risk and manage it. Their goal is to make risk free profits through arbitrage.

In finance, behaviour of the people with the intention of being risk averse is to assume massive risk due to their ignorance. The behaviour of risk takers is to understand risk and only take it on when they are adequately compensated, often making profit with no risk.

When attempting to transform an IT function, most executives are risk averse. They seek to hire experts who will manage the risk for them. The problem with hiring experts is that you really need to be an expert to hire them otherwise you will not know whether they are an expert or a smart person reading one chapter ahead of you. As a result, executives tend to appoint big name consultancies so they cannot be blamed as an individual if things do not work out. Robyn Dymond has written an excellent article on the subject. The reality is that most big name consultancies have little or no depth of Agile experience. The big name consultancies are buying in experts themselves.

So what is needed for an executive to adopt the agile value of courage?

  1. The whole executive needs to work as a team to solve the problems that an Agile Transformation throws up. The CEO needs to act as the product owner and the CFO, COO, CPeopleO, CProductO, CMO, Business Heads need to act as a team rather than compete. They need to empower and support whichever executive is leading the transformation and help them remove impediments where ever they arise. This will allow the executive leading the transformation to manage the risk rather than go risk averse and appoint a big name consultancy. In other words, the executive team needs to model the behaviours that they want to organisation to adopt.
  2. The entire executive team need to engage in deep learning. Each executive should engage a number of coaches and commit several hours a week to learning about the new way of running the business. After all, they are transform their organisation and need to know how to run it when it has changed. This will mean new behaviours and patterns of working. It will almost certainly mean that all executives will need to “go to the Gemba” (Go to the place where work happens) rather than receive the majority of their intelligence through carefully manicured and filtered powerpoint decks.
  3. Executive will need to visit companies that are touted as successful. However, that is not enough. They need to use their existing employees and coaches to manage context risk. Get their team to attend conferences and find out the real stories behind the success. Understand if the solution they are looking to adopt will fit with their context. Most importantly, they should know what failures have been experienced by organisations adopting approaches.
  4. The executive leading the transformation should engage in several “safe to fail” experiments to try out different methods and approaches. They should try out one or two big name consultancies, as well as small niche Agile consultancies, and groups of independent experts. The only measure of success for these projects is real business benefit and not the production of paper or software “deliverables”. The IT Risk Management Framework might be useful for this.
  5. The executives need to understand that an Agile Transformation is hard and that some of the sacred cows of cost cutting need to be slain along the way.
  6. Any consultancy proposing a big bang, one size fits all approach should be shown to the door. That is exactly the reason the IT Risk Management Framework was created, so that teams and departments could adopt the most appropriate method for their context in the knowledge that the IT investment risk was managed if they operated within the constraints of the framework.
  7. Finally, executives need to understand that context is the most important thing for them to consider. They should become experts at managing risk and spotting when a solution does not map well to the context.

So whenever you are thinking that your executive is not acting with courage, understand that it is probably the team they are working with and the reward system they operate within that forces them to be risk averse. Its really hard to go back and learn a new way of thinking and doing, and it is something that will only really happen when you have the support of your team.


Executives and Safety

This is the third post on where Executives and Agile Experience diverge. It relates to the attitude towards creating a safe environment to work in and in particular the attitude towards “Get it done” individuals.

ScumFilmPosterEdited

“Get it done” Individuals

Executives love “Get it done” individuals. “Get it done” individuals agree a set of outputs and deliver them with ruthless efficiency and focus. “Get it done” individuals speak to executives in simple terms that the executives understand. In return, “Get it done” individuals focus on the results and nothing else. Anything that stands in the way of the agreed outputs is steamrollered in pursuit of the goal.

Agile environments are learning environments. In order to learn, people need safety, emotional safety and job safety. “Get it done” individuals are toxic in those environments. If you are an executive, and you want to create an Agile Environment that delivers outcomes rather than outputs, you need to have a zero tolerance to the following:

  1. Threats
  2. Abusive Behaviour
  3. Bullying
  4. Prejudice
  5. Cronyism
  6. Cliques
  7. Wilful Incompetence
  8. Over simplification
  9. Lying
  10. Failure to deliver outcomes

These are all tactics that “Get it done”.

Agile practitioners have a zero tolerance towards these tactics. If you do not stamp these out, especially in your “Get it done” individuals, your best performers will leave and you will be left with a culture of under-performance.

Threats, Abusive Behaviour and Bullying

You would think that in any modern organisation, threats, abusive behaviour and bullying would result in instant dismissal. However it turns out that these behaviours are tolerated by executives in “Get it done” individuals, especially if it is in the pursuit of results. “Get it done” individuals are expert at these tactics. Years of practice means that they know just how far they can go. They know what to say that gets the menace across without putting themselves or their career in danger. They have honed their tactics to know when they can most easily get away with it (late at night in an empty office is popular) and when they cannot (in a public place where there are independent minds that they cannot control).

These tactics mean that the “Get it done” individual can slice through argument and get things moving in the way they want. The fact that they might traumatize people in the process holds no interest for the executive.

Agile is all about learning. Individuals who embrace agile start to learn at a much faster rate than colleagues who do not. Learning means taking chances and trying new things. The result is that these individuals become much more valuable in the marketplace. When these individuals experience threats, abusive behaviour and bullying, they discover they have options, ones that pay them more, and ones that have better working conditions… ones without threats, abusive behaviour and bullying.

Prejudice

If you are an executive and you tolerate prejudice in your organisation, expect your best people to leave. Prejudice takes many forms. As well as racism, sexism, homophobia, beware of more subtle forms like roleism or employee type.

Agile as a community is bringing together all of the roles to work out better ways of delivering value. If your developers are allowed to abuse your testers and business analysts, good people will leave. Similarly consultants and permanent staff should not abuse contractors or vice versa.

As an executive, it is your responsibility to stamp out any form of prejuduce. Agile believes executives own that responsibility and should actively detect problems and remove them rather than turn a blind eye or claim that you were unaware. A failure to be aware of prejudice is no defence as it is the executive’s responsibility to know.

 

Cronyism and Cliques

“Get it done” individuals love cronies. They love people whose primary qualification is loyalty. They will happily deploy individuals who have neither the “Skill” and/or the “Will” to do a job, simply because that person will be loyal drone and act as a spy. “Get it done” individuals will happily employ people who add no value simply because they are loyal and spy for them, or drive through their agenda.

People  without the “Skill” and/or the “Will” create resentment in the hard working individuals who are delivering value because they have to work harder to carry them.

Experienced “Get it done” individuals will have a number of cronies who form a clique. The trusted individuals who drive through the “Get it done” individual’s agenda are also allowed to do whatever they choose. The clique get the credit because its the “Get it done” individual who delivers the message to executives. By comparison, Individuals outside the clique get no recognition by the “Get it done” individuals even though they are the ones doing the work.

Guess what the highly talented, delivery focused individuals do when they encounter cronies and cliques?

Executives in learning organisations “go to the Gemba”, they connect with people at all levels of the organisation. They make it easy for anyone to tell them about risks and issues. Successful executives in Agile organisations make themselves accessible. Individuals do not abuse the option to access power, they respect the individuals time and only come to them with important issues. Giving everyone access to power rather than just the select few means there are no stones unturned, or dark places for the cliques and cronies to hide beneath.

 

Wilful Incompetence and Over simplification

 

“Get it done” individuals celebrate the fact that they are not experts. They celebrate the fact that they are incompetent as if that was a positive quality. They are action oriented individuals who are experts at making decisions. They often make the wrong decisions but that is never their fault. They celebrate the fact that they can take complex and complicated situations and come up with an obvious solution. Einstein said…

Everything should be made as simple as possible, but no simpler.

“Get it done” individuals have simplified this statement further to form their own manifesto…

Everything should be made as simple as possible.

As a result, complex and complicated tasks like Lean and Agile transformations become reduced to a four step process:

  1. Measure the lead time
  2. Map the value stream
  3. Identify delays
  4. Remove delays

Executives love this simplification that removes the messiness of context and the challenges of understanding their customers and the things that they value.

Experts find themselves in meetings where they struggle to explain to executives that the over simplications are right… but utterly useless. Experts that discover they are valued more in other organisations where the executives share the view that “but no simpler” is just as important.

So Agile believes that Executives should learn about the things they lead. They should learn enough that “Get it done” individuals cannot violate the “but no simpler” rule.

Lying and Failure to deliver outcomes

Lying is an art form. Its harder to lie on an Agile project but it is still possible if executives lack experience with the Agile Toolkit. Executives that are new to Agile will be steered toward burn down charts, velocity graphs and lists of stories that are completed during a sprint. In other words, they will be steered towards activity and outputs rather than outcomes.

“Get it done” individuals will point to stories that demonstrate activity and inputs. They will point to the completion of features and stories.

Agile believes in transparency.

Agile practitioners understands that burn downs and velocity are tools for the team to help the team improve.

Agile practioners understand that progress is measure by achieving business value outcomes and showing progress toward delivering business value outcomes. (Progress is shown using cumulative flow diagrams.)

Executives are too tolerant toward “Get it done” individuals that fail to deliver business value outcomes. Executives are far too tolerant towards “Get it done” individuals who restate complex problems as complicated or obvious problems with a contractual check list of deliverables and outputs. Instead of “reduce churn in Asia”, the problem is restated as “build a blue widget” or create a “Service Blueprint” and a “Wireframe”.

If your deliverable does not involve an outcome involving the customer, you are probably being had.

“Get it done right!”

Agile practitioners “Get it done right”. They believe in delivering value with sustainable quality, and managing risk by reducing lead time and providing transparency.

In order to achieve this, the following constraints need to be applied by executives:

  1. Create a safe environment to learn, where it is safe to fail because individuals are taught how to create safe to fail experiments, and understand their risk limits.
  2. Have a zero tolerance to “Get it done” individuals or anyone for that matter who engage in any of the following.
    • Threats
    • Abusive Behaviour
    • Bullying
    • Prejudice
    • Cronyism
    • Cliques
    • Wilful Incompetence
    • Over simplification
    • Lying
    • Failure to deliver outcomes

Executives need to take responsibility for their organisations and the culture in their organisation. Not knowing is no longer an acceptable excuse.

 

 


Dragon Slayers and Farmers

This is the second post on where Executives and Agile Experience diverge. It relates to the attitude towards Dragon Slayers and Farmers.

CityOfLondonDragon

The Dragon Slayer

The executive sat in their office looking out toward the team. They hoped that today would be a quiet day, a day without Dragons. Draco arrived late and unpacked their back pack over their desk. Draco was often late because they nursed the system late into the early hours until it was stable and on its way to a successful run. Draco had saved the Executive’s job several times… a week… ever since the executive had taken over.

The executive opened outlook and started to scan their e:mails and mark them as urgent or important. As they worked down the list, a small crowd of the usual players gathered around Draco’s desk. Draco took a sip of their coffee as they listened, put down the coffee, and removed their glasses to pinch the bridge of their nose. They closed their eyes and remained still for a moment before silently nodding consent. How many times had the executive seem this ceremony play out? The players were headed towards their office. Behind them, the executive noted Giles and returned his wave. Giles pointed at their wrist indicating they would be over in five minutes for their one-to-one. Giles would push the executive for more money to invest in irrigation and fences, not an exciting decision for a battlefield commander. The delegation was now at the executive’s office. They paused at the threshold to make eye contact and agreement to progress. The executive waved them in and they rushed to their familiar spots around the executives small table, with the major positioned at the white board.

“Dragons! Dragons!”

The major cleared their throat. “The trades failed to cross the bridge. There was a new variant of trade that caused the check-point to fail.”

The executive nodded. “Go on.”

The major drew three squares on the white board and tapped on them before crossing one out. “I propose we clear the bridge, delete the offending trade and restart. We should be done by the deadline and the Prince need not know anything about it.”

Out of the corner of their eye, the executive saw Farmer Giles hovering at the threshold to the executive’s office. The executive waved the farmer away. The one-to-one would have to wait. There was a Dragon to slay!

The executive stared out his window at the office directly opposite. The office with a small leather sofa AND a small table. The office that they hoped would be theirs one day, providing the Dragons did not kill the executive’s career. “Draco, what do you think? Will it work.”

Draco blinked behind their thick glasses. Remained silent for a few seconds and then replied. “It won’t work. There are several reconciliation points which would fail later on as they check to make sure every trade is present.”

The major jumped in. “So what should we do?”

Draco, more confident now. “Lets clear the bridge. I’ll copy the bridge script and create a tweaked version for the new trade. We should hit the deadline.”

They turned to the executive who continued to stare out of the window. “Draco. Will it work?”

Draco was quick to answer. “Yes. It will”

The executive closed their eyes. This is a good decision for a battlefield commander. “Do it!” they said.

“I’ll get my men to clear the bridge and prepare for the script variant.” The major was happy to have a role to play in slaying the dragon. They all rushed from the executive’s office.

Later in the day, the executive looked up to see the Prince laughing and joking with Draco and the Major. The Prince saw the executive looking at them and waved. He strode over toward the executives office. “Great team you have here.” And then the Prince was gone.

The Farmer

The farmer signaled to the executive that they would join them in a few minutes as they passed behind Draco and co. The farmer checked the monitors for their system. Nothing had happened. Boring, boring, boring! Just as they liked it.

They dropped their bag on their desk and headed over to the executive’s office wondering whether their weekly one-to-one would happen. It was cancelled more often than not by a wondering Dragon that Draco needed to slay.

The executive waved the farmer away. They frowned, it would mean longer until they got more capacity in the lower field.

The farmer was grateful that they did not have to fight Dragons every day. The first few months had been hard. Early starts, late finishes and never a chance to help with the school run. The arguments with their partner because they could not take the kids to school or drop them off. Hiring the right people, shaving the Yak, introducing effective tests, removing technical debt. “Digging ditches and mending fences” as he explained to the executive and Prince. Now the system was boring, boring, boring. The farmer saw no reason to leave, provided they got the promotion they expected.

The Annual Appraisal

The executive hated the annual appraisal and promotion round. There were always people who were angry and annoyed. This year was going to be worse than normal, the Prince had told the executive that there would only be one promotion in their team. They would have to choose between Draco and Giles.

The executives focused on the questions that formed the promotion request.

“Please give evidence of leadership and problem solving.”

“Please give evidence of calm leadership under pressure.”

“Please give evidence of where the candidate has put the company first.”

It was easy to fill out the form for Draco. Draco filled the form several times a week. They barely knew Giles, it had been a month since the last one-to-one. He remember that he had been quite stressed when he started the job, and the executive had doubted their strategy of digging ditches and building fences when the dragons were flying overhead. In fact, the executive remembered feeling quite anxious about it all.

Besides, the Prince knew Draco well and did not know the Farmer at all.

The Aftermath

The executive was quite pleased with the way things were. Unfortunately Farmer Giles had left after it was announced that Draco would take over, something that had only been made possible by an ingenious double promotion. As soon as Giles and some of his team left it became apparent that they had been hiding things. Dragons had started to appear but luckily they had Draco in place to cope with them, the executive was sure that the system was now in safe hands. The executive looked forward to their new office.

The executive picked up the book in front of them “Agile Software Development” by Alistair Cockburn. Something about the story of the author’s son planting next year’s profit bothered them but they could not work out why.

Author’s note

There are a couple of points I want to confess to with this post…

  1. This is faction. It is based on several real experiences and observation made since first reading Alistair’s book.
  2. This is the first blog post I’ve tried to deliberately write in a gender neutral manner, trying to use “They”/”Them” instead of “He”/”She”. It was harder than I expected and it does not flow as well as I would like.
  3. The photo of the Dragon guarding the City of London was taken yesterday outside of Chancery Lane tube station. I tried to snap the Dragons in Moorgate and Bishopsgate but they are gone. Perhaps it is a sign that there are fewer Dragons in the city thanks to Agile?
  4. The photo is the first that I have edited. The dark original with tree branches and a tower is shown below side by side with the edited version finally used.

Screen Shot 2017-03-19 at 07.47.54

 

 

 

 

 

 

 

 


Where Executives and Agile Beliefs Diverge

It is a commonly held belief that Executives and Agile are aligned and the problem with Agile adoption lies with the Frozen Middle (Management). Although Agile and Executives are aligned on many things, there are some core beliefs where some executives diverge. This is the first post in a series that explores those areas where the divergence occurs.

Sustainable Pace

The easiest way to spot an IT executive who does not have experience on the front line as a developer or manager is their attitude to overtime. Anyone with experience as an agile developer or working closely with developers knows that any code written after six in the evening has to be rewritten at some point, ideally the following day but often at a later date when it costs more to fix. One of the core tenets of Agile is the concept of “sustainable pace“, that developers work at a pace that can be sustained over an indefinite period. This sustainable pace leads to more predictability regarding the delivery of value that gives business sponsors confidence and reliability. Sustainable pace reduces cost because it reduces staff turnover , especially experienced developers who have a choice as to where they work. In order to maintain a sustainable pace, managers need to ensure they have slack which is also contrary to the goals of many executives.

Sustainable Pace is particularly important when developers are following an Agile approach to development, or more precisely Extreme Programming (or Dev Ops as it often called these days). Extreme Programming is a very disciplined and rigorous approach to developing software. Developers follow the disciplined “Red-Green-Refactor” pattern. This approach requires discipline and focus that is enhanced by the practice of pair programming which further keeps developers focused on a problem and reduces interruption. Extreme Programming is rigorous and relentless, requiring both discipline and focus. Simply put, if a developer is following extreme programming practices, they are simply unable to work beyond 6pm for an extended period without becoming tired and making mistakes. These mistakes lead to reduced productivity and introduce uncertainty into the development process.

Cheap developers reduce costs

Associated with the belief that sustainable pace is unimportant is the belief that some executives have that cheap developers reduce cost. Experienced Agile Developers and managers that have worked with them know that good developers are much cheaper than inexperienced ones when you consider productivity. Experienced Agile developers “shave the Yak” as they go along. They ruthlessly refactor legacy code bases so that they can deliver value faster. They do not have have to do massive refactorings as a big batch but rather have the skills to continuously improve the code base. All of this whilst continuously improving the velocity at which they deliver value using the “Red-Green-Refactor” pattern.

Book of Dead Code

A few years ago I visited Nat Pryce and his team. They were looking after a complex code base to support a web site for complicated financial derivatives. Nat showed me a graph that plotted the number of lines of code over a six month period. Over six month his team had reduced the code base from a million lines of code to one hundred thousand. The code base was approximately ten percent of its original size.

I once worked with Steve Freeman on a project. In a few short weeks he reduced the size of one of the most complicated areas of the code base by 80% and trained the graduate on the team in Extreme Programming at the same time. The pair also wrapped the code base in automated tests as part of the process.

If you want to understand why that is so significant, consider the following two images. In which one is it easiest to spot the bug (Waldo)?

screen-shot-2017-03-04-at-17-16-57 screen-shot-2017-03-04-at-17-17-40

Some Agile Developers have a practice of creating a book of dead code. Code that has been deleted from legacy code bases that was unnecessary. A book of dead code is a good way of demonstrating to business investors how much unnecessary and wasteful code they have paid for because they hired inexperienced developers.

Inexperienced developers tend to generate bigger code bases as they “cut-and-paste” to solve problems. A lack of automated tests leads to risk aversion which means they avoid touching the original code and copy it instead, tweaking the new version and leaving the original untouched.

If you want to reduce your short and long term costs, invest in Agile developers who have extensive experience in Extreme Programming practices.

Value versus Cost

Unfortunately executives do not value experienced Agile developers. They prefer to hire cheap off shore developers who are often recent graduates in the belief that cheap is better than experience.

The reason for this is well known.

IT departments in traditional organisations have a pretty poor track record at delivering value. A few years ago I heard a quote from a CEO. It was something like “I love off-shoring. Now when a project fails, it does not cost as much“. This highlights the reality that business leaders do not trust their IT departments to deliver value, so they focus on reducing cost. Agile focuses on delivering value rather than reducing cost. Cost reduction occurs by only building features that customers value and avoiding the features that are not valued and therefore not used.

Good developers want to work with good developers

So now that we understand that hiring good developers is better than hiring cheap developers for reducing overall costs. How do we hire good developers?

Executives think that paying experienced developers is enough to motivate them. They think that coersion applied through the hierarchy and the appropriate (currently in vogue) reward and appraisal system is all that is needed to achieve the goals they set.

Good developers want to write good code. They look for environments where they are respected for their ability and managers and executives are constantly looking for ways to help the developers become more effective. Good developers want to work in an environment where they have the tools they need to perform. If they do not have those tools, they will move on.

Good Agile developers want to work with good agile developers. They want to develop their skills and they are not going to be able to do that working with a bunch of graduates.

The good news is if you create the conditions that allow developers to deliver, they will come to you. There are several companies in London with large clusters of Agile Developers. As soon as an Agile developer discovers a good place to work, they reach out to their friends to pull them in. That’s why companies like Springer, Sky, Net-A-Porter, BBC, that are known to be favorable environments for Agile developers. They do not need to advertise as developers make a bee line to them.

It takes time to establish a reputation as a “go to” agile organisation. For those organisations that want a kick start and for those executives who do not have access to the network of established agile practitioners, you might consider starting with established agile consultancies rather than those whose practice is based in waterfall. Consultancies like Equal Experts, BJSS, Zulkhe, Industrial Logic, Crisp and ThoughtWorks. The ideal is to hire the alumni of those consultancies.

Teams OVER Individuals

Executives who are experienced with agile appreciate the value of individuals and appreciate the value of gelled teams of experienced individuals even more. A few months ago Microsoft closed the London Office of Skype in a strategic reorganisation. Enlightened individuals at Amazon appreciated the opportunity this represented and at the end of the same day they were standing outside of the Skype office handing out Apple Macs to developers. They did not insisted on interviews but hired entire teams in one go.

Being ready to respond to an opportunity like that. That is true agile management.

Dragon Slayers and Farmers

In the next post I will discuss the divergent attitude towards Dragon Slayers and Farmers.


Work backwards & cognitive dissonance

My current hero is Dan Marsh. Dan is a business analyst who has just finished his apprenticeship at my client. Dan had the courage to say that what I taught about Feature Injection’s working backwards (That tea bag stuff) actually scared him. Subsequently we had a great session to understand what he found so scary. As a result we came up with the following approach to explain “Work Backwards”. I will explain the subtle but important changes at the end.

We are skipping the “Hunt the value” or “OO” part of Jennie’s “OOPSI” model. And lets assume we have designed one or more “Output” that satisfies our “Outcome” (Design Brief – “We satisfy the “Need” of a “Group of Customers” and as a result the business received value which we measure using a “Metric”).

Consider the Design Brief (As a “Super Fan” I have a need to know “where my favourite celebrities went to school and played their first gigs so that I can go on a pilgrimage” and as a result the company will get more “Super fans”). So the product squad have collaborated on and tested and user tested designs to the point they have an experiment they want to scale out to more of the “Super fans”.

The design they come up with is “A mobile phone app to enable you to do a walking tour of a city to see all the locations where your favourite celebrity lived and played). Something like…

celebritywalkingtourapp

We create an initial Epic to build the experimental product. “Mobile App One to meet Design Brief”. Normally at this point we would break the Epic into stories. Instead we write the Acceptance Criteria using the Given-When-Then format. We start with the Value in creating our value stream. the thing that gives value to the customer, the THEN…

  • THEN the application displays a map
  • AND the current location is at the center of the map
  • AND the location of celebrity sites
  • AND the name of the important celebrity sites

So what are the things that could go wrong? Lets consider these as TODO’s that we will come back to in this Epic or more likely in other Epics.

  • TODO – The centre of the maps is a specified location (e.g. Zip/Post Code)
  • TODO – There are no celebrity sites (An arrow at the edge of the map indicating direction of closest site?)
  • TODO – There are no important celebrity sites

We now consider when the app displays the map. The normal response is to suggest when the app is opened. Alternatively it could be when the phone is near to one of the sites.

  • WHEN the phone is within the specified distance

And another TODO which will almost certainly go into another Epic.

  • TODO – When the app is opened.

We need to update the THEN as well to include an alert.

  • THEN the application displays a map
  • AND the current location is at the center of the map
  • AND the location of celebrity sites
  • AND the name of the important celebrity sites
  • AND the phone alerts the user

Now we can look at the necessary conditions for this to happen.

  • GIVEN user has selected a celebrity
  • AND there are celebrity sites nearby
  • AND user has marked celebrity site as important
  • AND user has enabled location services
  • AND user has enabled alerts
  • AND the user is logged in.

With an associated set of TODOs that go in additional Epics…

  • TODO user has not selected a celebrity
  • TODO there are no celebrity sites nearby
  • TODO user has not marked celebrity site as important
  • TODO user has not enabled location services
  • TODO user has not enabled alerts
  • TODO user is not logged in

Each GIVEN becomes a THEN in another scenario… For example

  • THEN the user has selected a celebrity
  • WHEN the user “snapz” the celebrity
  • GIVEN the user has selected a celebrity site
  • AND the user is logged in

… with associated TODOs, And the GIVEN in this scenario becomes a THEN in another scenario.

  • THEN the user has selected a celebrity site
  • WHEN the user “snapz” a celebrity site
  • GIVEN the user is viewing the map
  • AND a celebrity site is visible on the map
  • AND the user is logged in

… with associated TODOs (Only a couple mentioned)

  • TODO – User is looking at the list of celebrities.
  • TODO – User selects a band with more than one member.

And the GIVEN in this scenario becomes a THEN in another scenario.

  • THEN the user is logged in
  • WHEN the user presents their thumb print to the phone
  • GIVEN the user has entered the app
  • AND has registered using their thumb print

TODO – User name and password… because everyone does it that way. Just like putting the engine at the front of the car because people are used to seeing the horses before the cart, and like the idea of putting the “Cart before the horse”.

We can visualise the pattern of the scenarios evolving from the output to the inputs as follows:

screen-shot-2017-02-11-at-20-12-51

Which we can summarise as:

screen-shot-2017-02-11-at-20-13-22

And then we can reveal the pattern more clearly if we zoom out even further (and I’ve changed the TODO’s to clear boxes) as follows:

screen-shot-2017-02-11-at-21-21-44

This is the insight that Dan Marsh gave me. This is a natural way for people to work, from left to right. That means the output is on the left and the inputs are on the right which is contrary to the way I have represented this in the past. Also the natural way to write for THEN-WHEN-GIVEN is top to bottom whereas I have been teaching them to write GIVEN-WHEN-THEN from bottom to top which is also counter to the way people think. The right to left representation that confused people is below:

screen-shot-2017-02-11-at-21-23-18

Dan also helped me understand the follow representation that I had used was also confusing.

screen-shot-2017-02-11-at-21-29-45

So from now on, the process flow to write scenarios is left to right, top to bottom, with the arrows pointing left to right.

Thank you Dan for being honest about your thoughts. I think this is a huge insight. 🙂

From now on, I’m going to remove the cognitive dissonance. From now on, Its all about working forward from the output to the inputs.

 


The Zeroth Constraint.

The Theory of Constraints offers a simple five step process:

  1. Identify the constraint
  2. Prioritise work at the constraint
  3. Optimise the constraint
  4. Add capacity to the constraint
  5. Goto 1

Often the hardest thing to do is step 1, to identify the constraint.

One of the main frustrations for a coach is that they can see the constraint but cannot convince the organisation that they need to address the constraint. This is because the organisation has not reached the state of conscious competence about the constraint. They may see the constraint but they do not value it. Paul Adams talk reveals that famous people make us aware of new things but we only adopt them (value them) if one or more of the four people close to us in that context value it.

This means that often before the organisation will accept the constraint, they must first see the coach as a close trusted advisor. In order to achieve this, the coach must first help the organisation remove the constraints that the organisation think are the most important. Even though the coach might be torn because Theory of Constraints shows that working on anything other than the constraint has no impact, they are actually working on the Zeroth Constraint. The Zeroth constraint is that the organisation do not see the coach as a close trusted advisor.

Coaches who do not address the zeroth constraint may find themselves frustrated or in conflict with the organisation they are coaching. They find themselves in this state because they are acting with integrity, they are trying to focus on the most valuable work for the organisation. However first, they need to align themselves and the organisation in terms of understand the value of fixing the true constraint. To do this, the coach may need to demonstrate that they can fix the constraints that bother the organisation even if they are not true constraints. Demonstrating this ability to address these constraints will give the organisation more confidence that the coach can help them fix constraints they might otherwise prefer not to acknowledge.

If you are coach who is worried about working on improving the system away from the constraint, feel confident that you are acting with integrity because you are working on the zeroth constraint.

This insight came out during a conversation with Tony Grout (of course). I would say it was his idea, he might say it was mine.