Consistency Coupling

Consistency Coupling

This about the desire to keep things consistent.

When a development team makes a change to a component that is part of a large system they can be proud of their implementation. It can becomes the “way things are done”. The rest of the code base is shunned because it doesn’t follow the new standard. Now there is a desire to go through the rest of the system the improve it in the same way.

Stop, wait!

  • How long is this going to take?
  • When we the team get back to delivering business features?
  • Are these changes really needed?

These are the questions hiding in the background. These are the questions some delivery team will brush under the carpet.


I can totally buy the argument that if you change the look and feel of your application in one place there are good reasons to ensure consistency across the whole application. Your users may become confused by inconsistent interface.s They may stop using your software as a result.

What I don’t buy is the assumption that  consistency should stop you releasing a new feature. Perhaps you are trying something out that looks brilliant to the delivery team but when rolled out might causes your users to run a mile. In these circumstances the impact of the new feature should be measured. Only then will you know the true impact.

So when inconsistencies can impact you value stream I can be to swayed. But when I here technical arguments that say that we have to stop delivering new features for a while because this code change that was made to component A now need to be implemented across components B, C, D and E.

Often A, B, C, D, E are independent logical services. So the argument is saying because we changed A, we also need to change B, C, D & E. This same to contradict the assertion that services should be independent. Are we really arguing that the cost of changing one service increases exponentially as we build new service?  That makes no sense. We have a service based architecture to decrease costs not increase them.

Services communicate through interfaces to reduce implementation coupling

Services communicate asynchronously to reduce temporal coupling

Enforcing consistency across a code base causes build time coupling

I total empathise with the delivery teams OCD when they open up the code and see that services A and B have a terrible implementation when compared to services C’s elegant version. But in constantly evolving code base, the code will never be perfect at any point to time. You can never stop the clock and make everything perfect and even if you could, the moment time started running again the code would diverge and perfection would dissolve. In this way a code base demonstrates entropy. Over time and without a positive influence a code base will tend to disorder.

Dealing with this as technical debt. When improvements are spotted log them and even spend an hour or so improving  them yourself. But be cautious. If you have improved some code in a service that is not part of the feature set your team is working on that code may not be released in the short term. It may never get released.  It has no value if it is not released, so it is important to ensure that you don’t get distracted from the work you “should” be doing.

But lets follow this dark path a little bit more. Lets say you have invested the time and you want to realise the value of the work. Now you have to release this service alongside the rest of the team’s work. Ideally this would have little impact but experience tells me

  1. The release process will be very so slightly more complex
  2. There are more things to go wrong
  3. You get more questions about why “Service B” needs to be released when this increment is about changes service A

More effort, more time and more cost. You have coupled your change to the bulk of the team work purely for consistencies sake. Expand this problem to many services and you’re back to your monolith and you no longer can deliver cheaply, frequently and reliably. All this for consistencies sake.

If your application is such that you should drive for consistency at all cost –  you need to accept that impact and deal with the consequences – namely changes are likely to be slow. This should be a very rare case. If your priority is getting new features to your customer then you may have to deal with the fact that you application’s code may not be consistency.

Advertisements

The Scrum Master, Technical Lead Contradiction

The Scrum Master, Technical Lead Contradiction

It is not hard to find blog posts, whitepapers and books that describe Agile transformation. Many focus of the start point and then discuss the benefits that the transformation created. Often much of the detail in the middle is skipped giving the impression the time between the start and the end is insignificant.

In practice many organisations find themselves in a hybrid state, not one thing or another. They realise that they need to change and have started on that road. On the flip side, whilst many changes have been implemented, that same organisation would not consider themselves lean or agile. Whilst in this state valuable characteristics will emerge but it is just as likely that aspects will emerge that are the worst of both worlds.

This post is about a hybrid role that is sometimes found in this middle ground. The role of a Scrum Master / Tech Lead Roles

Context

The organisation is not yet convinced of Agile delivery. They have heard of Scrum but they can’t see why they need at full time person to coach each team. And the rates this person charges are so high they’d better find thing else for them to do in the copious down time they’ll have!

Technical Lead

If you search for the term technical lead you’ll find many descriptions that range from project manager, architect to programmer. When you focus of on the common verbs in these descriptions you’ll find

  • Leads
  • Manages
  • In charge of
  • Accountable
  • Responsible

In a nutshell the Technical Lead often is expected to tell the rest of the team what to do and make all the technical decisions. Good technical leaders have the humility to delegate this to their team members but the results is the same, the rest of the organisation see the technical lead as the team

Scrum Master

The Scrum Master on the other hand helps the team to understand the processes and frameworks they should use to reach the state of a self-organising team where they themselves make the decisions and work out what they need to do. Rather than leading from the front they are a Servant Leader help the team become self-sufficient.

Conflict of Interests

As a team are learning the way of any Agile framework they can be very fragile. During a transformation they will be asked to fundamentally change and yet still deliver at a sustained rate. Change can be stressful at the best of time but it can unbearable while you are under deliver pressure.

So, when the team is being coach by a Scrum Master who is also the Technical Lead that individual will have a very fine balance to find. They will be encouraged when their coaching effort generates visible improvement to the team. However it is invertible that the point will come where some stakeholder will lean on the Technical Lead part of the role. The incumbent will have to step in to “take charge” due to some pressure or other perhaps to avoid a costly mistake. There is a good chance that this action can undo many of the team’s improvements. This intervention can shatter the team’s illusion that they are accountable and they fall back to the relative comfort of being told what to do.

A Scrum Master is trying to make the team accountable The Technical lead is the only one accountable. Hence the conflict of interest.

When forming a new agile team it is important that the coach is dedicated and his not expected to be the defacto team leader. I would recommend to always have a dedicated Scrum Master but not everyone sees eye to eye with me on that. In that case it might be acceptable to give the Scrum Master role to one of the team members but only when they are a self-organising team for some time.

 

Silos – Agile Anti Patterns

Silos – Agile Anti Patterns

Last time I wrote about Work in Progress and why you should managed it to avoid creating bottlenecks. Silos cause bottlenecks. So this time I want to share my thoughts about why you often fine silos in a software delivery teams.

Organising a team around technology

In large organisations you might find IT functional units such as UX teams or database teams. The company organisation treats IT functions like business units. This might make sense on paper, but delivering software requires much tighter collaboration.

This results in each team focusing are their own work. The system they are part of is a secondary consideration. They tend to optimise themselves around their own workload. When this goes bad, the rest of the system becomes a customer.

You want this database changing?

Fill in this service request and we’ll get to it when we are ready!

Pressure to keep everyone in the team busy

Lets face it. Often the people who deliver software projects are not always seen as people. They are resources that need to optimising. You might feel a pressure from above to “make sure everyone is busy”. You must find new work to keep “resources” busy. The pressure comes from people striving for efficiency over effectiveness. Good results can only come from busy specialists because they “cost” the most. The motivation is financial rather than delivering a quality product.

What this does it increase the team’s work in progress as your specialists start more work to “get a head start”. When they finish their part, the value is not realised as the rest of the team catch up. The work stacks up unfinished.

We have to accept that people are expensive. A desire to maximise the return on investment will never go away. The answer, if you care about team effectiveness, is not to shape the work to fit the skillset in the team. Instead the answer is to fit the team to the work by encouraging generalists.

Lack of Definition of Done

The definition of done is a key elements in fostering team focus. It counters the individualism you find when a bunch of specialist come together. Without it you may experience the “Many type of dones”. The most common is development done where work is “thrown over the wall”. It is even more frustrating when the wall is a desk partition.

When a team of generalist form, and they focus of collaborating on a prioritise backlog. As the do so, the silos seem to evaporate. Everyone is busy although they might not be working on their preferred tasks. Project managers are not required as the team organises themselves around the work. There is no need for someone to move the work from person to person. And those that hold the purse strings have a warm feeling. The feeling that comes from predictability and knowing that no-one is under utilised.

Ignoring Work in Progress – Agile Anti Patterns

Ignoring Work in Progress – Agile Anti Patterns

What does Work in Progress mean?

Work in progress is a measure of the amount of work at a particular state of a workflow. What this means in practice is the amount of individual development tasks currently being undertaken by an individual or a count of how many widgets are at the same stage of a manufacturing process concurrently.

Why is it important and why shouldn’t it be ignored?

As it turns out, Work in Progress is a very important element in understanding the effectiveness of a team.  Experience shows that optimising the Work in Progress by determined an appropriate limit for each stage of a workflow can increase the rate at which work can flow through a workflow and therefore increase the effectiveness of a team. In effect, it encourages a team to focus on what is important at any given moment and reduces the impacts of context switching by limiting the amount of work being done at any point in time. Observing work in progress highlights blockers and bottlenecks clearly and obviously.

Given that this should seem like common sense to you it isn’t surprising that minimising work in progress features prominently in most “Agile” frameworks.

However, in practice common sense is not always applied.  In the wild you’ll often encounter teams that don’t manage their WIP limits. They will argue stubbornly that what you are suggesting, having the whole team focus of a small number of activities, is some sort of snake oil that will limit rather than improve the team. What you as an outsider will observe will include some or all of the following

  • Individuals seem busy but feel like they are never achieving anything. You will hear statements such as “I have not got any real work done today”. In fact they spend most of their time context switching.
  • Many pieces of work will be started but a lot less will be finished. There might be a sense that the team is on a death march and never gets to do the improvements that are desperately called for. Worst the team cost effectiveness may be in question.
  • Sometimes the result of a team rather than individuals dealing with too much work is a bottleneck later in the process. I often see this happens when there is an imbalance between development and testing. In order to eliminate the backlog of development work ready for testing stacking up, the work in progress limit for development should be reduced. In a multi skilled team this might free up enough people to clear the backlog quicker.

The first step towards minimising work in progress is to understand whether you have a problem. The simplest way to do this is to use a Kanban board and measure the number of items at a given status at any point in time.  It should be immediately apparent where the most work is occurring. It is then possible to set limits to ensure that the flow of work through the team’s process is maintained. Once you are comfortable with that a cumulative flow diagram provides a deeper view of the work flowing through a process over time. This might show for example that a Scrum team has too much work stacked up in “design” at the start of a sprint, and the same thing happens to work in “testing” at the end of the sprint. Using this insight, the team may self-organise themselves to limit these bottlenecks which results in a better flow overall.

Kanban CFD_1

That is the easy part. The hard part is getting the team to redistribute themselves to get the work flowing through and to avoid management types from thinking the key to optimising flow is by playing convoluted games of Resource Planning Tetris.

 

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.