Can being remote enhance agility?

I am a very lucky person, I have my dream job. I work for a huge Solutions Provider as a member of their software consultancy group. The consultancy group has multiple physical offices in the St Louis area, and offices in Denver, New York and London. we have now decided to expand into the virtual space and launch a Virtual Office dedicated to collaborative software delivery. My role is to create this office, define the tools, practices, processes and then to build the team: hiring and supporting the staff and managing and growing the office. It is an incredible opportunity and it is not overstating to say that I wake up excited (and daunted) about it every day.

I wrote a while ago about the new role and about the challenge of remaining true to an Agile mindset. My goal was not to lose our agility as we became separated by technology and tools. https://yorkesoftware.com/2018/10/11/a-3-pipe-problem/

It was a surprise to discover that with the right attitudes and the right tools we are actually able to enhance our agility. We are actually more agile in a virtual space than we were in the physical space.

What is Agility?

To many this will sound like an exaggeration, but as a consultancy firm we sometimes operate in a less than optimal situation, there are challenges when you are working in a slightly abstracted situation. To be truly ‘Agile’ the goal is generally to get the team and business working together and to shorten feedback loops, deliver software quickly. But the reality is that ‘the business’ is a client. They are removed often physically which is bad enough but often they have other priorities and so are removed in an availability sense too. So whilst our teams are together, it is rare that we get the business (SMEs and Product Owners) on site and embedded with our team, when we can this is the ideal situation.

More often we get together for project kick-offs and planning and regularly for demos and retros. But stand-ups are often conducted via web conferencing tools, as are story writing and weekly planning/prioritization meetings. This puts a barrier between the team and the business, we do our best to break down these barriers but the reality is that they exist.

I call out being a consultancy as it is an extreme case but it also happens in most businesses, the PO and SMEs generally have another job and other priorities and the development team gets a slice of time and attention, so this is not unique to consultancy.

Brave New World

So understandably I went into this new venture with the expectation of doing my best to mitigate an already existing problem and to strive to not let it be worse in a Virtual Team.

In the early stages we found a tool called Sococo which is very hard to describe as technically it offers the same as many other remote communication tools, but it uses the metaphor of a physical office to make it easy for us to relate to the situation. When we used this tool something quite amazing happened, suddenly we were in the same metaphoric space as ‘the business’, we were truly working together. If I had a question for the PO I can drop by their office. If we need clarification from a SME we can invite them to join an Ad-hoc meeting.

We were no longer waiting for scheduled meetings to ask questions, we were chatting immediately. Feedback loops became immediate conversations, if someone was busy they would drop in between calls or other meetings rather than scheduling something formal. The casual nature of the metaphor brought us all together. This is how I imagined agile teams should behave in an office, but all too often logistics (read lack of meeting rooms) meant this was rarely a reality.

As a little tangent I worked with a delivery team a few years ago where the PO was available to the team all day but was in an office maybe a 60 second walk away. She made it clear the team could drop by or call her. But they never did. As an experiment I asked her to sit at a desk in the team area, immediately the team was a buzz of questions and conversation, we worked faster and discussions were spontaneous and relevant to the work at hand. This is how Sococo feels now. I can’t express how excited I am about it.

Daily Demos

An interesting thing has happened too, the team had an aspirational goal of daily demos, demonstrating completed stories and getting feedback on direction each day at stand-up. The aim was to challenge the team to keep stories small and to focus on shortening the feedback loop.

What happened instead was the realization that you don’t need to wait for stand-up. When a story was done the team would pull everyone together immediately get feedback and then discuss and plan what was next.

We realized that scheduled meetings for everything from story writing to stand-ups were primarily about availability of people and especially meeting rooms, they had little to do with the product or agility. When not restricted by availability of meeting rooms you can simply talk about what is needed when you need to. It is so liberating.
Naturally such a change requires a great deal of discipline to be effective but you have the potential to be focused on the shortest feedback loop, and reacting immediately.

By moving to a virtual environment we are becoming more agile than we were even together in the office, and having fun doing it. These may not sound like ground breaking discoveries but I can assure you they are having a profound impact on our work.

Introduction to Lean – Slides

Slides from the presentation this evening at the Agile Product Ownership St Louis Meetup group.

The talk was a very high level overview of Lean thinking and how the wastes can be applied to software delivery.

Meetup

For those interested in joining future meet-ups, we are open to all. The group is aimed at those interested in Agile and in particular the Product Ownership aspects of it.

Agile Product Ownership St. Louis

Monday, Feb 11, 2019, 6:00 PM

World Wide Technology
701 Fee Fee Road Maryland Heights, MO

4 Members Attending

Lightning talk and then if we have time a general Q&A Please join us: 6:00-6:15 Meet and Greet 6:15-6:30 Lightning talk! 6:30-7:15 Q&A / Discussion

Check out this Meetup →

Topics are varied and not always limited to Agile as was the case this evening where we explored Lean thinking and how it applied to software delivery.

Remote attendance

For those unable to attend in person we are now offering remote attendance via Webex.

We meet on the second Monday of each month. We hope to see you at the next meetup.

A 3-pipe problem

Sherlock Holmes was a master of deductive reasoning and problem solving, rarely was a problem beyond his capability. However, every once in a while he encountered problems that required a greater level of consideration, it would stretch his mind to it’s limits and required him not to be disturbed for an extended period, he described these as 3-pipe problems, he would need the time it took for him to smoke three pipes.

IMG_0640

I am no Holmes but I have the joy of a 3-pipe problem to immerse myself in. I have been asked to lead an endeavour to create, build and run a virtual office comprising of cross-functional teams that create software. The challenge is to grow an office but maintain agility, retain our company culture, and have the teams happy and engaged. Oh and be profitable too.

Where I have seen remote work successful in the past has been where there were clear tasks assigned and collaboration was a minor element of the work. My observations of many remote workplaces is that they focus on individual contributions, collaboration is asynchronous and there is a heavy overhead of management assigning tasks.

What I am envisioning is a workplace where the team is self organised, and whilst there is likely an increased element of asynchronous working it will be alongside effective collaboration. I see my role as identifying healthy boundaries that enable collaboration and creativity.

36509555 - remote work or global wi-fi internet connection

Communication

Naturally communication is key, just as it is in brick and mortar offices, but when we are face to face we have a lifetime of skills to rely on. Instinctive awareness of body language, sensing mood and tone, not to mention touch – hand shakes and physical contact create bonds we don’t fully understand.

Remote teams communicating effectively is far more complex than simply joining a webex. I see the ability to communicate and collaborate as the number 1 challenge of this role.

Why this?

As an agile coach I strongly support the Agile manifesto (alongside Lean, ToC, and Lean Startup) and the manifesto favours individuals and interactions over processes and tools. It also advocates face to face communication. And yet I am taking on a role that is putting barriers between people and pretty soon I’ll be talking about how processes tools are vital for enhancing individuals in their interactions.

So why take on a job that seemingly flies in the face of this? The answer is twofold, First I believe the manifesto is a mindset for guiding teams in improving their way of working to get better at delivering software. I believe we can adhere to that mindset in this environment, I don’t see a conflict. Secondly I think that the focus and scope of the manifesto didn’t consider the larger picture and the changing state of the workers needs. Face to face is better – no argument from me, but it comes at a cost. We need to weigh up what is lost and what is gained from remote working and decide if what we gain is worth the sacrifice and I think with the right attitude, training and tools the desired outcome of effective collaboration can still be achieved and achieved in a way that is better for many team members.

What is more, I think this will be one of the most challenging coaching roles I have faced. Just like teams, coaching is far more effective face to face. The coaching may take on a different dynamic but I still very much see this as a coaching role.

Processes and Tools.

I warned you! To have effective communication and collaboration in a virtual workplace processes and tools are vital ,and are a prerequisite to the individuals and their interactions. But I don’t see a conflict here, in face to face communication there are processes and tools, we just don’t feel the need to mention them as they are natural to us.

Don’t shout, don’t mumble, don’t interrupt, pay attention, look at the speaker, be respectful. Lots of processes and a lot of non-verbal communication. And just watch for hand gestures or pens on post-it’s or whiteboards these are all tools, we hardly consider them that way and we certainly wouldn’t object to any of those processes or tools, they are necessary for our interactions.

In a virtual world the need is the same but the tools are different, tone of voice and body language are harder to decipher, so we need to be more attentive and more explicit. pen and paper are replaced with online collaboration tools, shared screens, electronic gestures and Slack messages to clarify misunderstandings.

IMG_0639

The scope of the task is daunting but I so excited about this. My employer is already a leader in Agile software delivery, this is the chance to demonstrate that we can be agile about flexible work environments without sacrificing what has made us successful: collaboration and self-organization.

This blog will continue to be Agile focused but I’ll also share some of the experiments as we discover what works for us.

Rewarding voluntary overtime.

I was chatting to a friend recently, he is a manager of an IT department and I used to manage a software department before I became a Agile Coach so we tend to talk a lot about management techniques and especially how a lot of the successful traditional techniques map to an agile work environment.

It was performance review time and the topic of conversation got around to a frustrating belief by some staff that working long hours without being asked is something that should have an implied reward. That working long hours is in itself a reason to be praised.

clock

Warning signs

I can’t speak for all managers, but for the two of us I can say that we consider it to be the opposite, when someone works late on a regular basis without being asked, we see that as a bad thing, it is a red-flag. Certainly not to be commended and very likely a sign of deeper problems.

I used to pride myself on being a good manager, I felt I was fair and sought to do what was best for my employees and the business, sometimes it was a fine line and often not easy. But one of my strongest principles was to be fair. I would never assign someone more work than I felt they could handle (that is not to say I didn’t seek to challenge them), I would generally discuss in advance what they felt was fair and I would always say very clearly that they should come back to me if they had problems, and I would review on a regular basis – usually at least weekly.

As an Agile Coach I have obviously changed my behaviour a lot and learned so much along the way but generally speaking it could be said that the roles are reversed, the team decide what they feel they can commit to and they review with each other on a regular basis (at the daily stand-up) and can ask if they need help, they should assign themselves small chunks of work and no more than can be reasonably achieved.

Salary man working overtime Overload. Cartoon Illustration.

Have I assigned too much?

In either of these scenarios there should be no scope for voluntary, unpaid, overtime.  In the case of assigned work: if you cannot get it done in the allotted time then it is a failure of my management – either I have incorrectly assessed the amount of work or I have misjudged the individuals capability to do it, and unless I have opportunity to be aware of that I cannot correct my behaviour and the cycle will repeat.

The same is true in Agile, whichever chosen framework you use the model is built on empirical evidence, if your forecasts are off you learn and adjust next time. Working overtime hides problems and perpetuates failing cycles, it also causes an imbalance in the team, it makes pair programming difficult and sends mixed messages to others. Very simply as a team manager or a self-organizing Team you cannot fix a problem you don’t know about.  Overtime is analogous to cards not on the board, it is hiding work, this is very damaging to a self-organising team.

Rewarding bad behaviour

So should you reward someone for working late, for their dedication and loyalty? or should they be reprimanded for their lack of transparency, or their inefficiency of working? Are they displaying a lack of courage in not challenging an unrealistic expectation? Are they stretching work to appear more busy? Should we reward their failure to communicate an excessive workload, or for failing to ask for help with their lack of knowledge/training/understanding to achieve the objective at hand?

As a manager if I ask you to work overtime I would do so with a very heavy heart, I know that it is not good for you, I know it is not good for the business and any gain is short-term and short-lived. It will only be in exceptional circumstances, where there is justification or benefit in working overtime.

As a member of a self-organizing team you should set those same standards for yourself: You should know that it is not good for you or the team, You should know it is not good for the business and any gain is short-lived.

So if you do voluntary overtime which conflicts with our team plans or expectations please don’t expect to be rewarded for it. That may sound harsh but I value communication far more than I value you giving extra time, especially if by doing so it is hiding problems elsewhere that we could and should be addressing.

overtime

Clarification

This is not a call to work to rule, this is a request to understand the difference between being a team player and expecting recognition and reward for setting yourself up as a martyr. By doing so, try to understand that you are working against the interests of the team, this is not behaviour we should be rewarding.

Sometimes it is necessary to work overtime but this should be a deliberate team decision with a clear objective. It should be open and transparent and should not be one person acting alone.

*Note when I saw reward, this is everything from a positive comment from leadership to financial reward. Sometimes leadership even acknowledging this behaviour is seen as a reward, the belief that your actions were noticed is quite an incentive for some.

Isn’t it obvious?

I occasionally get asked why and how I became an Agile Coach and whether it is a fulfilling role. When I began my career I certainly had no intention or expectation to be here, I was a software developer, I loved writing code and like most developers I wanted to create something that made a difference.

What followed was 15 years of… I want to say frustration but that is unfair because I generally loved my work and got to create some great software, but I always had this belief that there was a better way, a more effective way to get the job done, I dabbled in project management and team management believing I could do better than those I had worked for in the past.  My problem and I suspect it is a very common problem is that I spent a lot of effort trying to do my job better, to be more efficient, more effective, to deliver more etc. etc. It turns out that was wrong and I was wasting a lot of effort and not getting the results I expected.

deadly-assumptions

And then quite by accident (and for all the wrong reasons) I stumbled on to Scrum. I was running a software department and we were forever fire-fighting and I saw Scrum as a tool I could use to control the workflow and manage the demands on the team. It worked, and in the breathing room it created I was inspired to look deeper, beyond Scrum to Agile, and then Lean and Systems thinking and the Theory of Constraints and then I saw it. I felt like I had discovered the meaning of the universe, and once you see it you can’t un-see it, you see it everywhere, it feels like it is staring you in the face.

There is nothing more deceptive than an obvious fact. 
― Arthur Conan Doyle

c770ba6b2c578be3db267493229de2dc

Of course I hadn’t discovered anything, I had just opened my eyes and it was right there in front of me and it was so unbelievably obvious that it almost feels stupid writing this.

And it is this simple:

All we have to do is work on the thing that adds the most value and stop working on things that don’t add value.

Work on the thing that adds the most value and stop working on things that don’t add value.

So I said it was simple but it took me 15 years to start to understand it and nearly 10 years later I am still figuring it out, because whilst it is so simple that it should have been obvious all along, it is also remarkably difficult to do.

What is Value?

The primary problem is to understand what value is. figuring out your value stream in a system is key, and to be fair most businesses do this to some extent, but most individuals do not understand how they fit into the system they are in, nor do they understand how their local system fits into the big picture.

We cannot see the value we contribute to the system and when we don’t see what is most valuable, we do what we see as most valuable in our line of sight. Crazy as that sounds it is nearly always the wrong thing, optimizing for us nearly always optimizes against the larger system. The bigger the organisation the more this happens and the more inefficient it gets.

opportunity cost

  • the loss of potential gain from other alternatives when one alternative is chosen.

Another aspect is that so much value is obfuscated, it gets lost in opportunity cost which is invisible on balance sheets and yet is likely the biggest cost you pay when developing software. Or cash flow, leverage and return on investment, these are fundamental aspects of successful business but they are generally encapsulated and decoupled from the parts of the business that can impact them most – especially IT and software product development. Many projects get given budgets and time lines, which is a horrible way to run a business and it cripples cash flow, it also significantly limits investment opportunities and increases risk significantly.  But worst of all it delays delivering value.

Two Problems

So that is actually two problems, first is that we need to figure out what is valuable and then we have to communicate that to those doing the work.

In that sentence is the heart of being an Agile Coach, my role has become one of helping organisations understand their value stream, especially how software impacts and interacts with it, helping visualise that value and prioritise it and then to help communicate that to those that will create the software and deliver that value as quickly as possible.

  • Discover what our goal is – how do we deliver value? What outcome are we trying to achieve? 
  • Communicate that to everyone so we each know how we help to get towards the goal and how we avoid getting in the way.

 

Unfortunately the majority of the time is spent dealing with people that are just like I was, they are doing their very best to be as efficient and possible in their domain, simply because they cannot trace what they are doing to the value delivered.  So I spend much of my time doing my best to help them see that often what they are doing is at best not achieving anything useful and more often is actually damaging to the bigger picture.

Example

victoriaspongecomet

Let me give an example that a friend of mine shared recently:  My friend was baking some cakes for an event and needed to bake 10 cakes, but only had one oven. Her husband offered to help out and so she asked him to measure out the ingredients for the cakes in advance so that it would be quicker to get the next cake in the oven.

When she came to get the ingredients for the cake, they were not ready, her husband had optimised for himself and not for the goal.  He concluded it would be much more efficient for him to measure out 10 batches of flour then 10 of… etc.  after all he knew they would be needed later and it was quicker and far more efficient for him to do that than to do small batches and keep switching.

The result was that whilst he was being efficient for himself, the system grinds to a halt and must wait, his efficiency came at the cost of massive losses to value delivery (cakes baked).

Perhaps if he had understood the full picture, and how his contribution impacted the value stream he would have planned his work differently? He would have prepared one cake at a time even though it was less efficient for him. Together they would have reached the true goal more quickly.

But the funniest part of this story for me was that she was so frustrated,  she thought it was obvious, and he thought he was being efficient.  Those opposing view points are so common in this line of work.

When you see it, it is obvious but until you do it remains an enigma.

Why be a coach?

doc

Now imagine that confusion on an industrial scale, a whole organisation of people conscientiously working hard in the belief they are being efficient but still struggling to deliver software, delivering software that is not what is wanted, features that are not needed, struggling with integration and so on.  Then this loony guy comes in and says that you might actually contribute more by being less efficient.  – I’m the loony guy and I love it.

Agile is a mindset for getting better at delivering software and coaching is about helping you. But my goal is not to help you improve just a part of the system, the goal is to help you improve the system, and that starts by helping you and the whole organisation see the system. and learn how to communicate where we can add value.

Obviously there is a lot more to Agile than communication and value, but in my experience if you figure those out the rest falls in to place.

—————————————

There are a handful of books that I repeatedly recommend, all of which display true Agility and yet to be contrary not one is about ‘Agile’

The Advantage by Patrick Lencioni 

This talks about being clear in your goal and how to communicate it to your organisation, it is not quite as specific as I am hinting at in the article as we must delve deeper but it is an amazing book and the emphasis is on over-communication.

The Goal by Eli Goldratt

This book uses a production plant as a metaphor for delivering value to your customers. The emphasis is on the manufacturing equivalent of delivering working software, doing it regularly, and that delivery is not about development, OR production OR deployment it is about everything – essentially encouraging Dev Ops.  It also has a lot to say about the non-sense of Dev-Done and how the only Done that matters is to have it in your customers’ hands.

Read it!  This is hands down the best book on Agility I have ever read.  There are many others by this author all of which are great but this is my favourite.

The 5-Dysfunctions of a Team by Patrick Lencioni

I wholeheartedly subscribe to the Lencioni school of thought on many things (hence two books by him in this short list). On team building this is one of the best books out there, it describes the stages of team development, and you see this time and time again. Team dynamics are such a crucial part of agility and fundamental to success, this helps teams see those stages and is a great tool for helping teams bond.

 

What does agility mean to you?

It seems like there is a very personal level to what Agile Software Development means, as far as I can tell there is no consistent common understanding of what agility means. Some see it as a framework, others as a mindset.

Why-Agility-is-Critical-for-Soccer-Players-STACK

For me it means two things.

We have agility in our planning. We expect and encourage our plan to change as we better understand what we are delivering.

And

We have agility in our operations. We expect and encourage our tools processes and methods to change as we discover better ways of doing things.

Planning

Agility in planning means making a plan: ‘failure to plan’ as they say is ‘planning to fail’, and that failure is probably more certain than than it was when we had an inflexible plan.  There is a great deal of value in planning, we learn a lot and by setting a sense of direction we create focus.

The trick is that if we understand what we are planning and why we are planning, we can do it in the most efficient and effective way. We don’t need a lot of planning or a lot of detail, planning doesn’t need to be a massive overhead.

If we limit the granularity of our plan in relation to how far ahead we are planning then we allow for that plan to adapt as we get more information.  We can get all the benefit of having a plan without the overhead and without being restricted if and when the plan needs to change.

Business-Agility_450

Process

I believe process is vital to success in business, whether we are building software or hiring or in a factory, even sales has a process.  But a process must be flexible, we must be able to adapt when things change and we must be able to react to exceptions.

We mustn’t ever get to a point where we declare this is the ‘best’ way of doing something or ‘if it ain’t broke don’t fix it’   As soon as we stop looking we prove ourselves right, if we only know one way to do something it is definitely the best that we know of. Our ignorance ensures that we are right.  But if getting better is more important than being blissfully ignorant then we must look for ways to improve, we need to observe and we need to experiment. We should never let entropy set in, we should always be seeking to improve.

The very best processes build in opportunities for reflection and improvement, ensuring a mindset that there is always a better way, is far healthier than one of complacency.

One of my favourite ‘processes’ comes from the Theory of Constraints, it starts with the assumption that something can be improved and the first step is to identify the one area that would most benefit from improvement, it ends with a refusal to accept inertia.

TOC 5 Steps

 

Summary

For many Agile is about the framework, or the tools, for others it is the people and their ability to self-organise.  I don’t want to devalue those aspects but I see those as a means to achieve the agility in planning and process.

I’d love to hear your thoughts, what does Agile mean to you?

 

 

 

A tale of two engineers.

There are two ships traveling a busy shipping route, each ship has a complex engine and the engineering team has a chief engineer. Both ships are a similar age and size.

The first ship has a very busy chief engineer running this way and that, fixing any and every problem that comes up, he knows every inch of the engine and many parts of it are custom made by him. He is dirty and oily and hard working, whenever there is a problem – and there are many problems – he is on hand to fix it. He is dedicated and hard working, he works long hours and is always ready and willing to get his hands dirty. Without him the ship couldn’t function.

The second chief engineer has spent his time not fixing things, if a part is unreliable he has replaced it, if a component is troublesome it is gone. If there is a problem he ensures one of his team fixes it (with guidance initially) and will encourage them to spread the knowledge so that after a while he rarely if ever gets his hands dirty. He is rarely dirty or oily and it is a very rare situation to see him fixing anything. On many voyages he can seemingly sit there with his feet up doing very little in maintaining the ship and can use his time on other productive activities. Frankly if he missed a voyage the ship would probably run just fine without him.

Now which in your opinion is the better chief engineer?  I know which one I would rather have on my team.

It is often said that the goal of a good Scrum Master is to make themselves redundant, I take exception to this a little I think as in the tale above it is possible to create a situation where you are not necessarily needed all the time. But I wonder how long a team would last as a top-performing team if the Scrum Master was taken away, perhaps in the short term no one would notice, but growing and shaping and coaching a team takes time and effort, but slipping back into bad habits can happen quickly. Creating a situation where the Scrum Master has time to do other things is a good thing and a reflection of success not a sign he is not needed. A Scrum Master that is essential to a team is one that has failed, in fact if ever you feel you have an employee you are overly dependent on you have a serious issue.

How many top athletes would say “I’ve reached me peak I no longer need my coach”? My guess is that if they feel they have reached their peak they will seek out a new coach that can push those limits further.

A good coach or Scrum Master guides the team to independence, and then pushes their limits further.  They may be more useful elsewhere but that is very different from becoming redundant.