Making a Difference…

Enterprise Agility is not about backlogs and scrums. Enterprise Agility is not about processes or practices. Thought leaders and conference speakers will talk in reverent tones about Mindsets, Culture and Values, which are all important aspects but are easier to pontificate on than actually do anything about.

Enterprise Agility is really about being better, and that “Agility” word really means an empirical approach in the face of a VUCA environment – and when it comes to corporate operations they are almost the definition of Volatile, Uncertain, Complex and Ambiguous environments. Really what we are talking about here is ENTERPRISE IMPROVEMENT – and that is something readily understandable and desirable to all levels of a company.

Improvement is a very different concept to a description of an idealised state. Many organisations will sell the utopian state of an organisation. A place where throngs of passionate employees collaborate to deliver high revenue driving products or services, supported by cutting age technology, that are loved by their customers. There are plenty of frameworks that will lay out exactly how this will function, how the teams are structured, how the work flows, how the engineering standards are specified and more. This is all wonderful and makes for great sales materials, but it is also an aspirational fiction. Organisations don’t need help to understand what the vision should be, or what a “best in class” delivery function looks like – they likely already know. What they really want and where they need help, is much more mundane. “How can I improve, what path should I take?”

To answer this critical question there needs to be a switch to focus on WHERE WE ARE and the IMMEDIATE STEPS to improvement, rather than on defining an unrealistic unachievable future state. One thing I have observed from the most powerful and successful companies in the world is that they all have a ruthless and effective attitude towards self improvement.

To quote someone of pedigree:

“The important thing is not your process. The important thing is the process for improving your process” Henrik Kniberg

Given that this improvement is where we should invest, the approach that is to be taken is much more akin to a coaching enterprise Kanban than a more expected consulting “fait accompli” style.

If this resonates and you are in the crosshairs of needing that transformation to materialise, then here are some critical first steps to take:

Self Assess

Measure the current state and be public about these measures – giving you a lever to align efforts and to justify the celebration of success. The atmosphere in the company will open up giving options and ideas for improvement with collective ownership, avoiding the otherwise inevitable resistance that comes with top down imposition of change.

Having organisation level metrics will ensure that the changes that are made are holistic, avoiding localised optimisation which feels progressive at the time, but drives siloes and systemic dysfunction

No Sacred Cows

Be hard on the current situation. “What got you here, won’t get you there…” The processes, policies and behaviours that currently exist were all created for rational reasons, but it is often the case that those reasons no longer apply. It used to be illegal for taxis not to carry hay so as to ensure the welfare of the horses, but the horses vanished long before the law did. Undesirable consequences come when people become responsible for the execution of process, rather than the benefits that those processes deliver. People in these situations often look to preserve those processes long after their benefits have vanished because they provide purpose and career security. A move to betterment will challenge the underlying assumptions of existing processes and practices to ensure that the benefits justify the overhead. If the people involved become invested in the benefits, those antiquated processes and practices will soon be discarded.

Conscious Ignorance

Ignorance is such a powerful word, loaded with judgement. Yet there is so much that is unknown and so much that be said to be unknowable up front. We should not be ashamed about this. I am ignorant on eighteenth century Mexican history, there is no shame in that, I can’t know everything. To make out that I do, or to expect others to, is deeply unhelpful and prevents us from learning. To learn we first have to accept a degree of conscious ignorance and then a sense of curiosity.

More subtle is to accept that I could be wrong, to appreciate that while I have knowledge or understanding, it could be flawed or incomplete – without this we are unwilling to accommodate any opinions that do not align with ours.

To embrace continuous improvement we must accept that our world is complex and networked, that the changes that are made will have imprecise desired impact but also unpredictable consequences elsewhere. For example when jumping into water of unknown depth, the wise approach is not to jump from a great height. When the change is made, make it small enough to be able to manage the unknowns that are going to arise.

The challenge is not how to be right, but how to cope with being wrong – because we are wrong…

Change is the new normal.

The natural laws of entropy will erode the efficacy of any fixed approach, human or mechanical. We need to be changing just to stay still, let alone get ahead, so change needs to be seen as the new normal. Once change is commonplace then it is feared less and seen more as an opportunity. It also places the current state as transitory, which means that if there is something deficit about the status quo, then firstly we should change it, and secondly it is easier to put up with in the knowledge it won’t last long.

Accept the debt

Like when buying a house, when we saddle ourselves with debt to get onto the housing ladder, some changes have a degree of short term pain for long term gain. It is nearly unavoidable to make this proverbial omelette without breaking a few eggs. The pain is natural, resistance will be common due to the uncertainty it brings, and that resistance or even just the uncertainty can result in an immediate negative impact before the desired benefits kick in. This is to be expected but increases the importance of really monitoring the consequences of our actions, for should those benefits not materialise, then the change should be reconsidered. The risks taken here will of course be proportional to the scale of the change, so once again it pays to take lots of smaller changes over a single large step.

If your organisation is looking to transform, then following these five concepts will contribute to you starting down that path immediately rather than wasting time talking about a perfect world that is getting no closer.

Comments and feedback welcome

@philagiledesign

The Myth of Agile Anarchy – we no longer have any process!

The Agile Manifesto has been around a while now, although looking at many of the projects labelled Agile you’d be tempted to think nobody has read it. However, even when read, there are plenty of antipatterns in the industry stemming from misapplication of the Manifesto, resulting in rather cavalier behaviours that trend towards an undesirable anarchic state.

The Manifesto contains statements that prioritize focus on one side of four contrasting values, however the Manifesto does not state that the “other side” of the scale is not necessary or intrinsically bad; just that we focus on one side OVER the other. The Manifesto concludes “While there is value in the X…” Too often that has been misinterpreted as “Agile doesn’t include X”, giving rise to the Myth that Agile equals no process, Agile is the Wild West of Delivery….

Agile Manifesto value #1: Individuals and interactions over processes and tools

Just how much process and tooling is suitable?

Like an onion, the outer layer of processes and tooling are the most visible, and hence can be the easiest to adopt, like wearing a costume. That typically leads to a focus on processes and tools over individuals and interactions and is in my experience the single most common failing in attempts of Agile adoption. However – assuming you have avoided this pitfall, what processes and tools are sensible beyond those embedded in the software development system?

Processes

Scrum, and even Kanban, come with their own processes, do we need them? The original concept in Scrum, three roles, four events and three artefacts is a sensible starting point.

Scrum is a framework, and therefore, by definition, is incomplete; so customising it to meet your needs is expected, even necessary.  I’d argue that Scrum in a software context without underlying Extreme Programming  practices is likely to be a lot less successful than the other way round, but also many teams in any context will also have extra meetings, scheduled backlog refinement being a good example, or their own way to run retrospectives, or organise sprint planning. Many very common Agile concepts are not actually part of Scrum, User Stories, Planning Poker, Kanban Boards, etc., all of these are useful to some teams some of the time, it’s up to the team to decide if it’s right for them.

These concepts are not to be shot down in flames with a cry of “Processes are Evil”. This is due to the fact that in the majority of cases these customisations are ways of working that the team has intentionally adopted to simplify their activities, they might have even made them up. There is a significant difference between an externally defined process forced upon a team and an internally customised one, adopted from within. Rules (and by extension processes) enable action without full understanding, and consequently stifle innovation. Teams should be encouraged to regularly challenge their processes to ensure that they still support activities rather than restrict them. If you are going to have a process, then make sure the team owns it, and therefore is free to change it.

Processes are often the consequence of a lack of relationship. As the personal relationships between people become weaker, then processes are often brought in to compensate. Relationships can be strained either through failing trust or most commonly just due to scale. The growth pain organisations feel is partly a result of the shift from relationship and trust based operations, to one of process based. With good relationships within your team and the people around them, the need for processes is reduced. To establish where processes are necessary, approach the question in reverse and ask where and why the relationships are poor and how to improve them, then when they remain weak could a process help? Could it be that there already is a process and that is inhibiting relationships. One should always look to trust the person before trusting the process.  

Unless the whole organisation is Agile minded and relatively small, you are going to need to apply processes at the interfaces of poor relationships. That could be some structured status report into a nameless, faceless (at least from the perspective of a lowly team developer) steering committee, or maybe an agreed set of steps to request the support of an inflexible deployment team.

A consequence of the association between relationships and processes is that those team members that are not fully embedded in teams usually have more processes around their work than those in teams. So Policy Czars might have review sessions, User experience  might need their own schedule of work and SLAs to deliver against etc. Again, these aren’t intrinsically bad, but need to be agreed as a compensation for the lack of relationship rather than as an opportunity to reinforce it.

Processes as Common standards

When there are multiple teams working together there will always be some people that work across those teams, either operating above them or with multiples teams at once. These people tend to be fairly senior or specialized and their desire to be able to compare activity across the various teams will be a drive towards standardisation of process and practice. This is entirely reasonable and understandable but should not be taken to extremes.

Any output or practice from a team that is expected to interface with another team should be considered for mutual standardisation between those teams. This ensures that when they pass things from one to another, then there is clear understanding and fewer errors, it also enables the work from those two groups to be more easily aggregated. This is common sense and the errors on the space programme from teams working in metric units, versus those on imperial units is a great example of the risks of not doing so. However, we only want to standardise processes that have this cross-team impact, that contribute towards systemic alignment. There is a temptation to over standardize which is counter productive because it results in a loss of team control, and loss of control is a reduction in empowerment, autonomy and consequently engagement and ultimately performance.

For example, the Definition of Done for a delivery system is something that should be standardised, same for the format that requirements are written in and the syntax of a progress report, as all of these concern interfaces between teams. More team centric artefacts like Team Health Checks, Product Backlog refinement approach, and estimation approach are examples of things that could remain with the team because these are used internally to help themselves.

Tooling

So do we need one of those shiny Agile tracking tools, like JIRA, Version One, Rally or one of the others? Instead of assuming you do, try assuming you don’t and then establish why you do. If a tool is truly needed, specifically what elements of the tool you really need, rather than adopting it blindly wholesale. Distributed teams are usually one of the main drivers of tool use but these tools then risk becoming one of the biggest challenges to team interactions. Most teams, especially in our enforced distributed working era, will need a work tracking tool, but within that tool, stay focused on what you actually need, and try to limit it to that.

This is not to suggest that one should regard all tools with suspicion, with a degree of puritanical arrogance that things are somehow better, purer, without the crutch of tools. The point is to be objective. It is fairly well agreed that for effective Agile software delivery you are going to need some manner of continuous deployment. For example, it is common practice to have a tool to support code reviews and quality checks and many of these continuous deployment activities can now all be integrated into a single suite. These types of tools can be really helpful where the only guidelines are really that tooling should be brought in deliberately due to a defined need, rather than an assumed starting tool kit.

In summary

• All teams operating with Agile principles and values are likely to have processes, and an environment without any tools is likely to be quite inefficient. It is a complete Myth that Agile = No process
• Ensure that your processes don’t obstruct or disincentivise human relationships
• Processes are usually needed to provide a basic framework to show work and to harmonise group time
• Own your processes, externally applied processes can be damaging to engagement
• Consider all the relationships inside and outside the team. Wherever there are issues – either due to a lack of building trust or maintaining good communications, then consider adding a process
• Processes compensate for lack of relationship, only adopt to fill the gap and resist going further as you may reinforce the lack of relationship
• Process and Tooling will likely need to be standardised by the teams that use them for interfaces and common standards that affect their collective delivery on the same product or service

Catch me at @philagiledesign or https://www.linkedin.com/in/phil-thompson-65466b2/

Why aren’t my teams the best?

I have worked with many organisations, both large and small, in house and as an external consultant, and one question that is common is, “What was the best delivery you have seen?”, usually with the hope of emulating it.

Identifying examples of good delivery is relatively easy as long as you have sufficient experience. Eventually you’ll stumble on something good, you may even have had the knowledge, skill and luck to have enabled that “something good” to have occurred. What is much much harder is to find the common thread in them, what made them good? Or maybe the question should be what made the others less good?

 

The “best” teams in my experience used Scrum for the most part, so it would be tempting to say that because they used Scrum they became a good team. Personally I do not think this to be the case. I believe that they had some characteristics already which enabled Scrum to be effective. The Scrum framework and its underlying Agile principles would likely positively reinforce those characteristics, but the effective use of Scrum is a consequence not a driver in my opinion.

This also gives a counter corollary that if those characteristics are not present, then a team will struggle with Scrum, it will be seen as “A poor fit”; “Doesn’t work here” will be a common opinion.

The existence of these underlying characteristics can be considered to be assumptions that we make when looking at undertaking an Agile transformation. I don’t believe these are sufficiently understood or validated before people start talking about manifestos and associated principles and frameworks.

I would summarise these assumptions as the following:

• Our people work in teams
• Our leadership set an example
• Everyone is engaged to a common purpose

 

Teams

I have not encountered an organisation that would say they don’t deliver in teams, but often their definition of team doesn’t align to mine. A group of people under a common line manager does not constitute a team. Tom Loosemore, from GDS, I believe captured the essence in saying, “the unit of delivery is the team”. Simply a team is a group of people that have a common sense of success and failure; the success of one is defined by the success of all. If you operate in this manner then other characteristics such as collaboration will be a natural consequence.  For a team to identify with collective success they need a common purpose. If different team members are pursuing different goals then you will have a situation where some team members can feel they have achieved and others haven’t; at this point the team fractures, it is not really in their best interest to support each other. You can see how Scrum will grate on this type of delivery; there is little benefit one team member sharing what they did yesterday and will do today, if their peers do not have vested interest in that delivery.

Ideally teams will be cross functional, that is to say that they have all the skills needed to provide value within them. When some skills needed are outside the team, either you’ll build up dependencies to these external teams with the finger pointing that comes with it, or the team will look to do their best in that area with the skills they have; thereby bypassing the external team as much as possible, creating poorly used ivory towers of siloed skills.

We need to provide purpose,  and reward and recognise delivery at the team, rather than the individual level, if we want more than groups of people with a common line manager.

 

Leadership

What we want from our leaders is for them to set a direction, a vision, and series of goals and then enable everyone to be able to do their best, be their best to achieve it. When you hear tales of heroism in the military they are often justified with the phrase “they would do the same for me”. That is exposing the presence of real servant leadership, where the leaders primary concern is to bring out the best in their people and demonstrate the practices and behaviours that we should all adhere to. Our leaders shape the culture which defines the organisation. If we are looking for Agile principles to be adopted by our delivery teams they must first be adopted by our leaders, so the culture can be seen to be aligned. We can’t expect team COLLABORATION over team CONTRACTS if leadership are holding the delivery to a fixed time + scope contract. If we are looking to reduce work in progress at a team level, we must first look to reduce work in progress at a leadership level. As an example; I attended a presentation on an Agile Transformation within a UK high street bank at a MeetUp, this was floundering with a lot of process change but little benefit until they managed to show an Agile approach was being used at the board level to manage priorities and show transparency of effort, from that point on it became the path of least resistance (not no resistance mind).

We need to to be transparent about our Agile adoption at the highest levels of our organisation if we want the culture to align

 

Engagement

I have left this one till the end because it is the most powerful and the single biggest factor in my opinion between a successful team and one that isn’t. There was a Carnegie Institute of Technology study of successful people that gave the results that: success was 85% attitude and only 15% talent. The best team I have ever worked with wasn’t the smartest or most experienced, it was the one than cared the most.

I worked in a reasonably large multi team delivery some years back and one of the common complaints was “They don’t see the big picture”. I didn’t really understand this at the time, there was a lot of effort to explain the wider operation of the organisation and this project within it – with little result. I now understand the real issue was, “the teams delivering the system don’t seem to care as much about it as I do”.

In EVERY large multi team delivery system I have seen, this is a problem. Those systems are usually made of interdependent component teams where the concept of value is split across multiple teams. Here you have a separation of VALUE and DELIVERY. Many teams do not have the benefit of a personification of purpose within them. Their purpose is expressed as a contribution towards a goal owned somewhere else, by someone else, to be delivered at some point in the future. In this scenario is it very easy for heads to drop and a pervasive enterprise apathy creep in. At the heart of Agile, and facilitated by Scrum, is the concept of empirical improvement, if perpetual mediocrity is permissible then why go to the efforts of improvement?

Fundamentally Scrum works when you have something to deliver, if the consequences of lack of delivery are not felt personally and emotionally by the team, then the efforts required in Scrum will be resisted because the benefits aren’t really valuable – nobody really cares enough. Management may counter this by saying that they have been provided deadlines – but so are students for their end of term essays, which are typically started late and rushed, doing just what was needed, and this example matters a lot more than “someone else’s deadline.

One of the big differences between these large delivery systems and the smaller single team approach is how that Value or Purpose is personified. This is referred to as the Product Owner in Agile terminology –  someone who is emotionally, and ideally, physically present with a team through the delivery; not just at the start and the end.  They continually provide commitment for the team and are rewarded by commitment from the team. We may see the role in terms of their activities of requirements definition or prioritisation, but their greatest contribution is that they provide passion; they provide the team with drive – and simply – they often just aren’t there for each team in large delivery systems.

The problem is that drive is hard to measure and we naively assume that because the value can be articulated by a single person, then just one person is sufficient across the multiple teams involved to sustain the passion needed.

We need someone in each and every team who really cares about the outcome of the work if we want to sustain the maximum intensity in our delivery.

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me at @philagiledesign

 

 

 

 

 

Can a Teal society ever survive?

I recently attended an interesting talk on the nature of what it means to be a Teal organisation using the concepts from Frederic Laloux’s 2014 work “Reinventing Organizations”. If you aren’t familiar with the model then have a look at a good overview here The Future of Management is Teal.

 

I appreciate the premise that we can look to classify an organisation, or at least part of it at any moment in time, based on the levels of collaboration found within it. Classifying things is rewarding, we are not programmed to revel in chaos, small steps to push back against the entropy of the universe gives us a feeling of control. Simple classification however is a blunt and brutal tool and much of the conversation I listened to wisely warned against this. The world is not made up of purely Red, Orange or Brown companies with some Green ones looking enviously at the smug Teal one in the corner, it is much more nuanced than that, companies change and often demonstrate multiple behaviours within them at once.

There was an undercurrent in the talk that the progression through the colours to reach Teal was in someway more, “good”, representing a better citizen, and if we imagine a world where all companies were Teal then the world would be a better place – and it is hard to stand opposed to that. There were sensible points made that some functions within companies are well served by a more autocratic operation (distinctly not Teal), emergency triage, legal etc but it was clear that Teal is something to be aspired to. My point is that I am sufficiently pragmatic, grounded, realistic, cynical, bitter and twisted (depending on your perspective) to not believe that we will ever get there – and this is why:

 

There was one contributor that raised the concept that hierarchies will always exist, that really resonated with me. The response to this was that we should consider multiple hierarchies at once, varying by subject; so, I’d look to you in matters of finance and you’d look to me in matters of marketing. This inspires visions of a beautiful harmony of thoughts and decisions, swirling round an aspirational idea of mutual respect and oneness with others. It only takes a couple of steps for this organisational psychology to cross a line into spirituality and I think this is where I felt the conversation crossed an invisible line of pragmatism into ideology.

One of the other talks I attended made reference to the distinction between our primitive “Red” mind (cerebellum and limbic system), keeping us alive and giving emotion, and our thinking “Blue” mind (neocortex), giving us curiosity and reasoning. Our Red mind has been around for thousands of years whereas our Blue mind is a very recent development. I believe Teal organisations cater to our Blue mind, but what of our Red mind? The theory that gave this distinction also identified that the blue mind can only operate if the red mind is satisfied.

It is overly simplistic to see the world in terms of good and evil, but seeing as Laloux felt ok to categorise to make his point, for the purposes of making my point, I’ll carry on! In my experience people have immense capacity for goodness but equally the willfully destructive actions of some can have horrendous consequences on many. The more we ignore the opportunity for evil then the greater harm it can inflict, this is one reason we have a military even when at peace. The idea of a Teal state ignores the evil in us all, the desire for status, power and control. My concern is that the aspirational Teal state cannot be achieved because it requires a level of consistent goodness in us that we cannot sustain; there will always be at least one that succumbs to baser desires to the detriment of the society around them. This is not to mean that we should not aspire to this state, but not to be disheartened when we fail to achieve it, or sustain it.

In the image below I have crudely overlaid Laloux’s progress of organisations with humanity, where the lines cross represents the point beyond which the evil in society corrupts sufficiently as to prevent an ideal state. Clearly this is a graph without scale or metrics but I feel those lines cross well before we reach universal adoption of Teal behaviours.

Jessica Prentice’s excellent article, The most dangerous notion in “Reinventing Organizations” offers some solace. In it she reminds us that our culture has a depressing habit of after understanding something, believing we’ve invented it – the way that Christopher Columbus apparently discovered a new land, even though people had been living there for thousands of years already.

What she advocates is that societies long since crushed, using the example of Native American peoples, valued truthfulness, wisdom and community, and operated much closer to the Teal living organism paradigm than our capitalist societies of today. Therefore maybe it is something about our current society that enables the evil in us to run sufficiently wild as to prevent Teal being seen to be sustained. It is interesting to note that ideal state societies in literature such as the Elven kingdoms in Middle Earth or the Eloi in The Time Machine are very much more Teal than our current reality.

This isn’t to say it hasn’t been attempted, there have been multiple attempts to create a hierarchy-less collaborative “good” society. This has occurred in pockets, but small ones and usually not long lasting. A classic large-scale failure of this has to be the rise and fall of Communism in the twentieth century. The premise of the society is laudable, equal and harmonious, everyone working for everyone in a self-sustaining utopia; but when you remove the protections we have against humanity’s darkest capabilities the more terrifying their imposition becomes when inevitably they surface.

 

So where does this desire for status and control come from, if we consider that earlier societies didn’t have it to the same extent. Peter Drucker is purported to have said “you manage what you measure”, what if we take that to a societal level? Our current capitalist society measures, and by consequence judges, based on power and wealth. In such a society can a Teal organisation ever survive and thrive? A Teal organisation is likely to generate much goodwill and collaborative behaviours because that is what they are looking to optimise; but when pitted against an Orange “Machine” type organisation, according to the wider society’s measures of power and money, they are likely to lose out.

 

In conclusion while I will proudly state that I believe Teal characteristics as desirable and will continue to reward and nurture them where I find them; I am accepting, with a heavy heart, that I am unlikely to ever see this become the norm until the society I am in replaces power and money with collective fulfilment, as its measure of success.

 

Comments welcome

Phil Thompson

follow me on Twitter at @PhilAgileDesign

Agile is consuming itself

The biggest threats to wholesale agile adoption within our business society don’t come from a counter proposal, they come from within. The failings of previous approaches are well known and well documented and in fact have been since their inceptions, but everyone muddled through for lack of alternative. There isn’t going to be resurgence in support for the “Good old days”, too many people can prove it wasn’t that good. Nor do I imagine a new way, a utopian enlightenment to dawn upon us, from which point all programme delivery becomes risk and issue free, there just aren’t sufficient unexplored paradigms in our approach.

If the agile movement is to die, to collapse, it will do so inwards, on itself and from within. It will suffer the fate of Robespierre, the French revolutionary who rose to power through a fervent belief in equality and support for those that had been excluded and repressed under royal tyranny. His passion and success made him increasingly blind to the consequence of his unyielding beliefs and the presence of those that coveted his position. Eventually those that would usurp him turned the populace to revile the fanatical dogma that had wrought so much terror in the name of social progress, and he met the same end that he had brought about for the late king, a short drop from Madame Guillotine.

I suggest the dangers lie in three areas, the ignorant, the exploitative and the manipulative. In all cases the issue is misinterpretation of sound decent values, either innocently or more malevolently.

The first case is ignorance. This is a hard truth I had had to admit to myself, and I am reassured to read postings from other thought leaders I admire, who have humbled themselves in a similar fashion – see here, that has given me the confidence to come clean. Years ago I probably was this person, the well-intentioned but ignorant zealot; armed with too little understanding or experience of Agile Values and human politics, and too much theory and process definition.  I was that guy howling into the wilderness standing on Dunning-Kruger’s mount stupid. You’ve may relate to these kinds of transformation attempts; process and terminology centric backed by dogma and rhetoric that is applied through contextless retrospective coherence. Trying to change behaviours and practices through process, like trying to turn the quiet shy girl at the back of the class into the lead cheerleader by tossing her a costume and couple of pom-poms.

The second case is where the revenue generation consequence of those talented individuals working in organisations to support an agile transformation becomes a motivator for themselves and others. When the Agile philosophy becomes a commercial opportunity, then predictable but none too pleasant behaviours start to emerge. Pyramid style certification schemes, and an attempt to commoditise processes and supporting tooling for the purpose of revenue rather than stakeholder value. The worst excesses of this can be seen in those offerings that do little more than relabel existing familiar enterprise operations with new “Agiley” terminology with a supporting license fee. This undermines the Agile principles by dragging it down to something much closer to the status quo for the purpose of profit.

The last case is the most dangerous, those that speak in our name to further their own agendas. The butt of many a Dilbert joke – “Welcome to Agile – stop documenting anything and now you can work faster”. This is the wrecking ball of Agile, or more usually Scrum, wielded by paranoid power-hungry, non-technical managers who feel they now have a weapon to use against their intractable, awkward IT colleagues. Teams have been made to work longer, harder, with less control, fewer standards and more interference all in the name of Scrum. New developers have been born into this environment and are left believing that this is normal, and the more experienced developers resent the dumbing down on their industry and rage against the framework because they are powerless against their management. There are hundreds of comments on blog boards of people decrying Scrum through valid complaints about business practices that bear no resemblance to Scrum.

Now imagine all three together, well-intentioned but ignorant scrum masters being manipulated by untrusting and overly ambitious management to deliver the impossible, at the expense of the developer workforce, being cheered on by a process, tooling and certification industry laughing all the way to the bank. The end result will be a profitable industry of failing projects and people in a slightly different way to twenty years ago, and critically no real improvement in the enterprise project success rate.

So what is to be done? As a consultant working on Agile Transformation; are we like a few conservationists, trying to save what is left with the grim knowledge that it won’t be enough against the rampant consumerism, selfishness and apathy of humankind?

We have to continue, to give up would be dereliction of duty, and most of us have skin in the game ourselves now, we are part of the problem even as we try to point the finger elsewhere. Firstly we should point out misrepresentation of Agile wherever we see it. We need to stop preaching and learn a little humility, for those that teach Agile theory and concepts end each class with this statement – “you now know  a lot less than you think you do and are now capable of a lot more damage than you can imagine”. For those that are working in environments that are Agile in name only, then call this out, transformation to Agile may be beyond your means but at least stop calling it Agile so as to not further tarnish what was once a noble ideology. We need to focus on delivering value, on return for our clients not for ourselves. Be honest and ethical about the contracts we take and the companies we work for.

I like the proposition that someone attributed to McKinseys (I don’t know if correctly) that we should focus on delivering value to our clients rather than to ourselves and through that the money will flow anyway.

About me:

I am Phil Thompson, an Agile Consultant, have worked at many places in many industries and with many people, mostly in Europe, mostly in the UK, mostly in London. My opinions are my own, shaped and challenged by the people and companies I have been fortunate to work with over the past fifteen yrs.

You can reach me at @philagiledesign or LinkedIn

 

Mini Waterfall in your Agile sprint – Consider your testing role…

How many of you are running Scrum but struggle to get the burndown to be anywhere near the target – more often than not it sits flat and then drops down (to hopefully zero) in the last couple of days. I have even seen teams whose “target” burndown is a similar shape, they’d given up ever trying to get close to that constant gradient.

This is because the teams run mini waterfall inside their sprint. Each team member has their own role and the work is passed person to person (with a note saying, “done my bit, your problem now”) just like a whole project would be in a waterfall SDLC.

The most critical of these handovers is from a Developer to a Tester. This seems perfectly sensible, we know developers, we know testers, there is a natural flow of work. However this approach is fundamentally rooted in the past, reflecting practices and technologies which should now be dim and distant memories.

Firstly the tester role used to be more of an operations role, an experienced user trying every permutation they could think of to check it works. Now we are asking them to be more technically capable so they can test pieces of a flow, stubbing out inputs or outputs.

With an incremental delivery everyone has appreciated the importance of an automated regression test suite and as that has the word “test” in it –well give it to the tester. So there are teams out there with developers writing code and the super technically capable testers writing automated test scripts around it.

Stop everyone! This is taking the traditional siloed waterfall practices and hammering them into SCRUM until they almost fit. It is inefficient and enables individuals in teams to avoid ownership of delivery.

SCRUM is a reasonable approach for work management in iterative development but it has little to say on the technological approach other than the team members should be cross functional, to really get an Agile delivery to work you need to support it with XP – and inside that is the answer to the burndown gradient issue.

Within all the other good stuff in XP is the concept of TDD, Test DRIVEN development, where we write tests inside the code before writing the actual code. The important consequence of this for this piece, is that it is the developer that writes it. So the developer writes the code AND the tests. Horror screams the testers, for two reasons:

• “What about me, am I just redundant now?”
• And then secondly – after calming down for a moment – “we don’t trust the developers to check their own work, developers think differently to us, we consider all the options etc”

The first is an issue, the second a valid point and the solution to the first. If we change the focus of the tester to assure the work of the developer rather than the code (with focus on the coverage and approach of the automated tests) then the role brings genuine value to the team without necessitating an awkward handover.

I’d support renaming this role to be Quality Assurance, giving assurance to the team about the quality of the work done, this frees up the term tester for where it belongs and originated from. Genuine users in operations that can use the system to ensure that it does what is needed, ensuring there is no gap between what was designed and what was needed.

Operating with this approach will ensure that all team members are equally busy over the duration of the sprint and stories are pushed to “Done” consistently over the sprint rather than being pushed to a separate Test function who then close stories out at the sprint end.

As always happy for comments edits suggestions etc. @philagiledesign

Hello World

Something to open my blog site with…

What is scaled Agile. Well we know what Agile is, been enough books on the topic. I have often said that “Agile Doesn’t Scale” – but that is just a glib throw away remark aimed at those that think they can put a process in place, and, like a clockwork mouse, just let it go.

If we run on the premise that a small scale Agile (assume SCRUM) team is effective then multiples of that team would also be effective. However this will only remain true if the inputs and outputs of each team remain true to the original team’s principles. So you know what you want, you can deliver it in the team and what you do is put into production to gain learning for future work. Having multiple teams able to operate independently and a Dev Ops capable of deploying each team’s work is a rare situation – but if you have it then you have a wonderfully scaled agile project running with the same processes and governance that you had in the original small project.

And….. back in the real world where you have features that are being delivered by multiple teams, maybe over multiple sprints (moving to a multi-sprint release model) with dependencies in all directions, well then the original process and governance model doesn’t cut it any more. Now we enter the hot topic of the moment – how to apply processes and governance to enable Agile delivery at that scale without killing the goose that laid the golden egg.

So if you are going to ignore some of the basic principles of Agile Scrum projects by not immediately releasing and adding external dependencies then you are going to need some manner of process to compensate – if you don’t then you are in a world of anarchy. It is those processes that shape what we all know have come to accept as “Scaled Agile”. There is no right way to do that (although there are some wrong ways) and I hope to give (and learn) some thoughts on that topic in future posts.

Phil Thompson

Follow me on @philagiledesign