Asynchronous Stand-ups

Asynchronous Stand-ups

Working in distributed teams is always a challenge. This should come as no surprise as the Agile Manifesto contains the following

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

During face to face interactions you are picking up subtle hints through all of your senses. If you try to have the same conversation over the phone or on a textual medium such as email or a messaging system it will take much longer, there will be more misunderstandings and there is a high likelihood that all parties will come away with a slightly different perspective.

Face to face communication is not always possible. Sometimes the team is spread out geographically or perhaps different members of the team have different working patterns. In this situation, you will need to face up to how the distributed team synchronises – which is usually the purpose of the Daily Stand-up. But what does the daily stand-up look like when no-one is in the same physical space?

Firstly, a brief reminder of the purpose of the daily stand-up meeting.  This link gives my favourite definition at the moment.

Stand-ups are a mechanism to regularly synchronise so that teams…

  • Share understanding of goals. Even if we thought we understood each other at the start (which we probably didn’t), our understanding drifts, as does the context within which we’re operating. A “team” where each team member is working toward different goals tends to be ineffective.
  • Coordinate efforts. If the work doesn’t need to be coordinated, you don’t need a team. Conversely, if you have a team, I assume the work requires coordination. Poor coordination amongst team members tends to lead to poor outcomes.
  • Share problems and improvements. One of the primary benefits of a team versus working alone, is that team members can help each other when someone encounters a problem or discovers a better way of doing something. A “team” where team members are not comfortable sharing problems and/or do not help each other tends to be ineffective.
  • Identify as a team. It is very difficult to psychologically identify with a group if you don’t regularly engage with the group. You will not develop a strong sense of relatedness even if you believe them to be capable and pursuing the same goals.

When working patterns or geographic locations are challenges some teams do stand-ups asynchronously. What does that look like?

Asynchronous stand-ups attempt to meet the same goals of a regular stand up. The main difference is that it is done textually, on a messaging system. As each team members starts their day they write up what they did yesterday, today’s plan and blockers. All other messages from other team members are there to be read. And that’s about it.

The primary benefits are

  • • Suits distributed workers – Each team member can work when it suits them. They have a high level of flexibility to fit work around their lives.
  • Acts as a permanent record – All the stand-up messages live in the message system for ever and can be reviewed later.
  • Easy to distribute the information – All it takes for interested parties to see what is going on is to view a Slack channel or subscribe to a distribution list.

However, these are secondary benefits. If you analyse Asynchronous stand-ups against the goals above you see that they don’t easily enable any of them well.

  • Share understanding of goals. The focus is on the person and not the work. The messages are often about “what I did” not about how the team’s overall goals are being met. It is also difficult for a Scrum Master to provide context about the team’s goals and progress towards them when required.
  • Coordinate efforts. Whilst it is possible to coordinate effort using a textual medium it is harder, especially if not all parties are online at the same time. Asynchronous stand-ups favour individual approaches to problem solving rather than a coordinated one simply because the communication medium resists it. When coordination is necessary the model breaks down as a call is usually required. The other problem is that if you are the first person to start the day you’ll be posting your message into an empty stand-up. You’ll need to check back to see other team member posts.
  • Share problems and improvements. If someone asks for help or someone spots that they can help there is often a delay from the problem being reported on the Async stand-up to the team being able to share it. Perhaps the team member with the problem posted their message several hours before the rest of the team started. Since then they have spent a of couple hours “barking up the wrong tree”, or they are not watching the messaging system for responses because they “are in the zone” or even that they finished for the day. This leads to inefficiencies that are not easily overcome.
  • Identify as a team. Attempts to synchronise asynchronously re-enforces an individualistic over a team approach. And if this is the only means for the team to synchronise then that sense of relatedness will be very hard to develop.

It is possible to make this work to some degree. It requires discipline and regular inspection to ensure it is giving the team what it needs. For starters set some expectations about when people should be posting updates to give the team a chance to coordinate. Secondly set some rules that enable the team to get some context before posting, e.g., update any tracking tools and view the burn down. The Scrum master could post some contextual information at the end of their day so at least the first poster in the following stand up has something to go on.

It’s not a good idea to go 100% asynchronous though. Instead arrange periodic conference calls or video conferences within the sprint boundary.  If you don’t keep things in check, laziness will creep in and before you know it the team are going through the motions. It is easy to spot when the quality of the messages goes down and team members show signs of not understanding the team’s overall goals.

Modern software development is a collaborative experience. With modern audio and video technology there is no excuse for not having regular synchronous communication within your team. Yes, there is a cost but how much do you value an effective team? There is no place for developers working in a silo hiding behind a messaging system like Slack. And if the team doesn’t want to communicate, it is probably not a problem with how you do stand-ups, the problem lies more with the makeup of the team.

There are a couple of other perspectives of Asynchronous Stand-ups below

Backlog Black Hole – Agile Anti Patterns

Backlog Black Hole – Agile Anti Patterns

If I create a story and add it to the backlog, it will be lost forever and will never get done

A backlog is a prioritised list of work that needs to be done. The important stuff is at the top and the least important stuff at the bottom. If you find that work is “disappearing” in your backlog what could be the cause

  1. The backlog is not being maintained. The backlog is a living thing and as such needs feeding and watering. By that it needs near constant refinement. New work is discovered it gets added to the backlog. But what is happening to the existing stuff. All stories need to be reviewed not just the new ones. They need updating based on current knowledge. That might mean that the story is not required any longer and should be removed. Some people go so far as purging stories that have not been delivered based on their age. The thinking is that if a story gets to being 3 to 6 months old without being delivered then the chances are it will not be delivered in its current form at all.
  2. The newest work is the highest priority. Just because you have thought of the next killer feature it doesn’t automatically mean delivering that work is the highest priority. It should be assessed based on all the work in the backlog. If new work is always added to the top this starts to push older worked down, often meaning the team never get a chance to work on it.
  3. The work is not well defined. In order for someone to understand the work involved in a story it must be clear. If you are going to the trouble of adding work to the backlog that you think needs to be done you should also put in some effort to describe it. I’m not saying that you need to write “War and Peace” but you do need to represent the work to the Product Owner in ceremonies such as backlog refinement. In some circumstances, there are benefits to be found by having a triage process for new work. This provides a chance for the work to be reviewed by the necessary parties to ensure that it is understood, be prioritised and actually needed.
  4. You don’t have the right tools. A small team might get away with managing their backlog with sticky notes on a board. Large teams may need some tooling. Tooling can be an inhibitor as well as an enabler. So perhaps a tool has been implemented that is hard to use or that requires the team to be trained on. This might make it hard to find stories when you need them. Often it is possible to configure tools to provide reports of stories added in the last week or to enable integration with messaging tools such as slack so you have a constant stream of messages indicating new work entering the backlog.

Up to now this discussion has focused on the negative position that it is a bad thing that work is “being lost” in the backlog. However, when you think about it this may be a sign that you are doing the right thing. The work coming in may be aspirational or simply a wish list which is not what your customers really need. If you have an effective feedback loop you’ll be reacting to your customer’s needs rather than focusing on the things that they don’t care about.

Therefore, if you are the one coming up with the ideas that are not making it into the system you need to understand why. You can’t be precious about the work because it was “your idea”. This is looking at the product you’re building from a personal point of view and not considering how the product is used in reality. Perhaps you don’t understand the product as well as you think you do.

Finally, it is worth making a point around continuous technical improvement. My point of view is that for a product to be successful over a long period of time the technology it is built with needs to continuously evolve. Whether you call this technical debt or something else the point is that there will always be technical work that needs to be done that may not have direct value for the customer. The value is actually to your business as you’ll be able to continue to serve your customers in the future.

How you deal with this depends on the organisation. Often people implement a capacity tax that says that a given percentage of the team’s capacity goes towards technical improvement. This way the team are not asking for permission to improve things but there is a still need to document and prioritise the technical work that needs to be done. This is still a backlog. In other situations where the product owner is technically savvy and understands the relative value between delivering new features vs technical improvement, technical stories can be treated as any other work in the backlog.

Whichever way you look at this, it boils down to the fact that there is a pile of work that needs to be done. The work needs to be prioritised and each work item will have a different potential value to your customer and your business. And their needs to be way to make this work visible and transparent in an efficient manner.

Is Scrum anti Agile?

Is Scrum anti Agile?

When an organisation is moving from a top down process such as waterfall to an Agile methodology like Scrum, for the people involved it can feel like everything is coming off the rails. All the comfortable and reliable “process” is gone and now you really have to think. Change can be difficult and this type of change is no different.

When moving in this direction, a process or a framework is a safety net or a comfort blanket. If you are not careful people can miss the point of the Agile transformation and instead focus on the framework, methodology and tooling. Work management tools such as JIRA, which are a bit of a swiss army knife, can, if you are not careful, become another facet of the process safety net. Before long your work management tool is configured with so much “process” people have stopped thinking and any Agility that was blossoming in that organisation is slowly evaporating.

But let’s look at it from the other angle. Some small organisations have little to no process. From an outsider’s perspective, it looks like chaos but the reality is that these organisations have started from nothing and now have paying customers, so they must be doing something right.

These organisations might be looking to frameworks like Scrum to provide some stability and some predictability. They want to build on a successful foundation and grow without losing what made them special in the first place. So, you might look at implementing Scrum and related tooling simply to manage stories in a backlog. You might encourage using sprints to create a delivery cadence.

And then the backlash starts. In the same way waterfall practitioners think you are trying to take away their comfort blanket, so do the developers in the start-up that needs to mature. Whichever way you look at Scrum it has some rules. Okay, they may be called a framework but they are still rules. These rules drive home the point that to be stable and predictable you cannot have a free for all. The transforming organisation may start to realise that their current ways of working are not special and instead they need to conform with what the majority of the industry is doing.

In this situation, you must realise that processes or frameworks, even lightweight ones like Scrum, can be seen as a burden when transforming chaos into stability. While it might seem like common sense to you, the people undergoing the transformation may believe that agility is being lost, along with the innovation that got the organisation to that point in the first place.

 

Painting the Forth Bridge

Painting the Forth Bridge

They say that it takes so long to paint the Forth Bridge in Edinburgh, by the time the painting team have worked their way across the bridge, the paint at the start will need renewing, so they have to start again. This is of course, a myth, but if it were truth the workers painting the bridge would have a job for life.

Sometimes software projects are like this. They are in a state of perpetual rewrite. The rewrite may be needed because the wrong JavaScript framework was selected at the start so the team are moving to framework N which when completed will solve all problems. Or the application is considered a monolith so the team are “doing the right thing” breaking the solution up into Microservices. The “rewrite” is done with the best intentions but the outcome is often the same. The rewrite takes so long, that the IT world has moved on and now the goal the team is working towards is old fashioned and out of date, Fresh thinking is required, which triggers the next big rewrite and so the cycle continues, much like painting the proverbial bridge.

As professional technies, developers like solving the hard problems. They like using new technologies and the latest frameworks. However, it is a fact of life that most development work isn’t sexy or glamourous. Often developers spend a lot of time grinding out “business logic”, or fixing bugs. The work can become repetitive and boring. There is often a tension between the motivation to keep software development simpler and predictable through standardisation vs. a desire from the technical team to keep their skills fresh on the job.

For freelancers or developers working for software consultancies, getting stuck in one technical stack for a single project is not a problem. The next one is never too far away and it is likely to be very different. Change doesn’t come so frequently for those developers working in software houses. Typically they will be working longer terms on a smaller portfolio of projects and products. For software houses the economics are straight forwards, ship more products – make more money! Investing time in rewrites is a big challenge. Redirecting effort is large scale technical changes means they are not fixing bugs nor are they delivering as many features.

But if a product isn’t changing in pace with the technology landscape it is in danger of stagnating and becoming irrelevant. The software used to build it become out of date. The development team start to feel deskilled and may started to leave this business taking critical knowledge with them. It becomes harder to replace them as your technology stack is no longer attractive to the job market. Before you know it all the innovation that took you from a start up to a mature software house in the first place has leaked away.

As with everything there is a balance to be found. The development team need to be able to stay current but the organisation still needs to pay the bills. Here are a few things to look at to ensure that this balance is maintained.

Be aware of technical debt and pay it down frequently. This is simple really. The best way to avoid big changes in the first place is to fix problems soon after they occur. If they are left to mount up over time it become much harder to fix. Therefore, ensure that the team have the opportunity to fix things as part of the development process.

Ensure that the business value of large technical changes is understood. All work the development teams do should have a business value so ensure that this is understood when it comes to technical changes. There are often valid business reasons for changing from framework X to framework Y, but it is often hard to articulate. There is a temptation to avoid identifying the business value because it is hard to do, and instead the change is delivered as a side project or worst as someone’s pet project. Avoid this temptation as the term “side project” implies a lower priority so it is likely to be pushed to the side when your important customers are hammering down your door asking for the next great feature. Technical changes and evolving architecture is just as important as new features and so all the work should be in the same pot. The Product Owner must be given the hard problem of deciding whether to improve the system itself or deliver new features.

Ensure that large technical changes are delivered as a series of steps as part of a roadmap. Agile development is based on short feedback loops. This is no different when it comes to technical changes. Therefore, a big change should be broken into a roadmap. At the end of the roadmap is a goal and a vision, and at the beginning is a next few steps to get there. The idea is that you don’t create a detailed plan. You might only define the next few steps. This approach also allows the goals to change with little impact. It should be easy to get started as there is no long planning exercise which also means there is no temptation to follow through on a now invalid plan simply because too much cost has been sunken into the planning exercise.

Never ending stories – Agile Anti Patterns

Never ending stories – Agile Anti Patterns

The Never-Ending Story was a 1984 fantasy film about a boy who reads a magical book that tells a story of a young warrior whose task is to stop a dark storm called the Nothing from engulfing a fantasy world.  Apparently it was quite good but all I can remember about it is the large white flying dog like creature.

The Never-Ending stories I am more familiar with are those in Agile projects that start out as something that is assumed to be quite straight forwards but then generates much more work than was expected and before you know it, not only are you carrying it forwards into the next sprint but it starts reoccurring in multiple sprints. So, what are the characteristics of a never-ending story.

A story really represents a feature and as such becomes a bucket for all areas of functionality related to that feature

Agile is about reducing feedback loops in order to build confidence that you are always working on the most important thing at any given moment. Often never-ending stories internalise that feedback loop. Maybe the story represents a new area of a solution. You don’t what to do too much up front design or suffer from analysis paralysis so you have a story that enables you to try a few things out. This is reviewed with the Product Owner and the rest of the team which generates new ideas which is new work.

There is nothing wrong with this description so far, however a never-ending story emerges when that new work is added to the original story. Often this is coupled with a feeling that no one really knows what good looks like. The team starts to feel like they are working towards a moving target. It will only be a matter of time before the “When will you be done” questions start. Think for a minute about how it is possible to formulate an answer. Every time the team asks for feedback, more work is generated and so the goal has changed. Yet they are asked to say when work, which they may not know about yet, will be complete.

Work is blocked by external dependencies

Sometimes someone outside the team has a stake on when a story is complete. It may be that you are integrating with a third party and they have onboarding activities. Perhaps there is an external customer that has a final say on whether the work has been delivered to the necessary standard. The important thing to realise is that you cannot control this decision making and it is highly likely that your timescales will not align. The best thing to do is to accept it and then put in controls to minimise the impact on you.

There are a couple of things you can do to take control.

  1. Understand the requirements of the third parties upfront and ensure that this is factored in when creating the stories in the first place. This may feel like up front design but you are doing just enough to mitigate the risk of a delay in the future.
  2. Don’t “leave the bonnet open” on work whilst it is outside your control. Deal with feedback whether that is good or bad as new work coming into the backlog and deal with it on a priority basis.
  3. Minimise external dependencies by only having them when you absolutely can’t avoid them or where they add value to solutions you deliver.

Quality defects stopping work being completed

In this situation, the work has been done and the team’s tester is working on it only to find a quality issue. The story goes back to the developer to be fixed. Subsequently the tester picks up the work only to find more issues and repeat.  When this has been happening for some time, e.g., it is a reoccurring theme in multiple stand ups, the team needs to try to understand why things are bouncing around between two team members. Are the developer and tester working together on the story or is the developer “throwing the work over the wall”?  Are the defects being raised related to the changes being made under the story in question or are they coincidental. Are the developer and tester on the same page as to the quality metrics for the story?

So what?…

Never-ending stories are bad because they harm your team’s predictability. They are a black hole, they consume effort and people. No-one in your team is really sure when they will be complete. If you are working on one it can be very demoralising. Personally, I am motivated by finishing things but never-ending stories can really feel like a ball and chain, never allowing you to finish and never enabling you to move on to other things.

When you look at the examples I give there are a couple of ways to avoid never ending stories

Firstly, ensure that you are aware of the work that is being created. Whilst it is normal to create some new work when delivering stories, you need to decide the point at which you need to call it out, surfacing it as new work in the backlog and letting the PO prioritise it rather than absorbing it. If you are not doing this during a sprint, maybe when the story is carried over at a sprint boundary, this would be a good time to ask yourself if the story should be broken down.

Secondly many of the problems with defining the scope and boundary of a story could be resolve by investing time in defined acceptance criteria at the start. You may use a Story Kick-Off for this. The acceptance criteria could describe how the story should function, they define the quality criteria for the story and the expectations of third parties. And let’s not forget that we should be aiming to avoid large stories, breaking them down along their natural seams in order to keep your team predictable and high performing.

The state of “Not Invented Here Syndrome” in 2017

The state of “Not Invented Here Syndrome” in 2017

Development teams often build up high levels of trust internally due to the nature of the constant collaboration between team members.  Whilst that internal trust increases and increases, it can cause a lack of trust of outsiders whether that be 3rd parties or even other internal teams. So, when there is a genuine case for reuse there is often a strong argument against it. A common one is that the high-quality standards of the team can only be assured if code is written in house.

And why not. Developers like writing code, therefore given the chance they will write “all the code”. But code has a cost in terms on maintaining a solution over time. And we will have to support the solution because software isn’t written once then forgotten about, it continuously evolves. And let’s not forget that writing scalable, reliable and adaptable distributed systems is hard.  Who really wants to be debugging a custom load balancing solution when your system is on its knees and customers are beating down your door. Why invest the next couple of months building yet another custom security solution when your competitors seem to be releasing new features every few weeks.

The IT industry is seeing trends that will hopefully consign that old insular mindset to the history books.

Cloud computing offers, amongst many other advantages, the opportunity of offloading complexity on to some other party. Why worry about heating and air conditioning in a custom data centre when all you really need to do is build a website? Economies of scale means that costs are substantially reduced but you need to remember that cloud offerings are built for the masses and if you don’t fit then you may not get the benefits you expected. Cloud solutions such as Azure and Amazon Web Services practically offer a menu of services that you pick based on your requirements for ease of use vs the flexibility and control that you need. At the extreme, serverless computing promises that you can deploy and run code in the cloud without ever worrying about how the underlying infrastructure will be scaled to meet demand.

There is a trend where many companies are reinventing themselves as tech companies – Netflix and Amazon are just a couple of examples of companies that in order to be disruptive in their particular marketplaces transformed themselves into technology companies. Over the last few years this has reached a tipping point and now many organisations are trying the same thing and expecting the same results. Whilst it is true that IT is fundamental to many business models and being technically savvy as an organisation has a key role to play it is unlikely that everyone needs to code their IT from the ground up.

By looking at the first movers in that space you see technologies being developed in house to solve a particular problem and then shared back to the community. Google created AngularJS and Facebook the Cassandra NoSQL database. Today anyone can pick up these projects for their own use and perhaps more importantly they can contribute to them allowing them to evolve independently.

So, my vision of a team that is successfully avoiding NIH Syndrome in 2017 is one that

  • Has a wide understanding of the technology landscape
  • Does not exhibit siloed thinking about technology stacks, particular products or architectures
  • Has the time and space to try new things
  • And is encourage to contribute back into the community that they take from.

Reusing open source software is not like picking apples from somebody else’s orchard. It is a two-way proposition. You use an open source project to enhance your own product – usually to save cost and time. Therefore, you should invest some of that time back even if it is to simply fix bugs or answer questions on Stack overflow. And here in lies the challenge. Many organisations do not yet see the value of reinvesting in the community that bootstrapped them to where they are today and are so single minded they cannot see beyond their own immediate business pressures to deliver more features. Whether this approach is sustainable – I’m not sure. But as more and more companies transform into technology companies the cream of the development world will come to expect certain values from their employers and as you know the cream rises to the top.

 

 

 

 

Permission, Ability and Skills

Permission, Ability and Skills

It could be argued that the primary purpose of a software developer is to provide solutions to problems. Problems are presented in the form of requirements or user stories and it is the software developers job to provide a solution. They provide a solution with the tools that are available and within the constraints that exist within the organisation in which they work. Normally this is done unconsciously and we don’t stop to think about it. We open of our IDE of choice and start coding.

It is only when we start to encounter what might be considered more difficult problems, we start to see the limitations of this approach. What happens if the problem is that of building up a continuous delivery approach for your team or providing a level of disaster recovery for your product’s infrastructure.

Torturous Analogy Time.

Let imagine that the problem is that I need to travel from London to New York for conference. I have permission from my organisation to do this but I have no other help.  Let say I work for an aircraft manufacturer and they have a plane sitting outside ready to be used. They don’t want to waste money on buying a standard airline ticket when they have a £multi-million asset sitting outside. (I told you this is torturous!). So now I have the ability to get from London to New York but that still isn’t helping me because I can’t fly the plane, I don’t have the necessary skills.

In order to solve the problem I need the permission to tackle it, the ability, through technical support and the skills to use that technology to solve the problem at hand.

In software development we’ll nearly always have the permission and tools but that is not always enough to solve the big problems such as those a mentioned above – building up a continuous delivery approach for your team or providing a level of disaster recovery for your product’s infrastructure.

Solving the big problems often requires organisational transformations which require at least three aspects to change – people, process and tools.  Simply having the tools is not normally enough.  It like having the plane without the skill to fly it. As technologists, we want to believe that it is the tool that provides the solution to a problem, but it isn’t.

We are doing ourselves a misjustice really. We provide the skills that ultimately solve the problem. The technology simple provides the ability to bring those skills to bear.