Tag: software development

Are all developers equal?

In Scrum, only 3 roles are prescribed; Product Owner, Scrum Master and Developer (Team Member). It suggests that we let go of our traditional roles (and job titles) to form an embedded team, that collaborates and cross-skills.

“All developers are equal, but some developers are more equal than others”

I have spoken to several project and delivery managers who struggle to envisage this approach working in the real world. Their opinion is typically that contrary to Scrum’s idealistic vision, in practice they need to be able to map specialisations (and therefore, roles) into a project team to ensure that the relevant skills and experience are present to set it up for success.

They assert that the hard reality is that not everyone is a “superstar” that is able to generalise (certainly to the standard required) and that Scrum doesn’t work in its purest (or purist) form with team members of varying levels of ability. For example, a dedicated tester may be adept at test-automation, whereas a junior C# developer may lack this experience. Your project will vary in quality and speed of delivery depending on the composition of the team.

Discussion

I’d be interested to hear how people have addressed (the perception of) this issue and how they try to ensure each of their Scrum teams has the right mix of skills to guarantee success?

Please share your thoughts and experience by posting your comments below. 🙂

The role of an Agile architect

“Architecture is about the important stuff. Whatever that is.”

That’s what Martin Fowler told us way back in 2003. If you’re interested in the field of software architecture, it’s probably a quote you’re already familiar with. It’s often repeated, but it doesn’t really help explain what architecture is – or why it’s important. If we continue reading the same article, Fowler goes on to highlight a quote that goes a little further, from Ralph Johnson:

“Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other.”

Software development would be oh-so-easy if there was a reliable way to create a completely fit for purpose and efficient design up-front. Agile emerged partly from a realisation that our understanding of what we need will always change over the course of our development efforts. That could just mean adding more detail to our understanding or changing it substantially – that’s why we actively strive to respond to change in the way we work.

Even if we’re in an unlikely situation where we have a complete understanding of what we want now, there is very little chance we’ll know exactly how to solve all the problems we’re going to face getting there. We could spend lots of time up-front, acknowledging that there are risks with a completely predictive approach – or we could spend very little (or no) time in up-front design, reacting to any problems as they become known. Many Agile projects choose the latter and as a result produce less than elegant solutions – and are rightly criticised for it as a result…

How much forethought is enough?

We can’t accurately predict the future, so it seems a little unwise to rely on our precision in that area. Likewise, an entirely reactive approach is probably not going to be very efficient either – especially if we’re forced to rework large areas of our solution on a regular basis. So, we’re faced with a choice about how much time (and to what level of detail) we should invest in the architecture of our solution up-front. Talking about Agile Modelling, Scott Ambler described his “just barely good enough” approach:

I like to say they are just barely good enough (JBGE). I make the following critical points about a model or document (an artifact) being just barely good enough:

  • It is actually the most effective possible
  • It is situational
  • It does not imply low quality
  • It changes over time
  • It comes sooner than you think

All fairly self-explanatory, but in relation to his last point, he expands his explanation to include a very astute observation:

“Traditionalists seem to assume that significant investment in modeling, and corresponding specification, will continue to add value over time.”

This is a common assumption I’ve encountered many times myself. Funnily enough, in situations where the delivery of a project is delayed (or even derailed) by poor architectural decisions emerging after new information surfaces part-way through the delivery process, the response is often: “Go back, spend more time up-front and this time do it right!

If the previous activity exposed the only show-stopper your design will encounter, there’s a chance you’ll now be equipped with the information required to address the problem. The problem with this attitude is that in complex systems (and many simpler ones) there’s likely to be a whole host of potential show-stoppers – many in competition with each other. So what is the answer?

My advice echoes Scott’s – do just enough. What that looks like is highly situational, it doesn’t mean you can accept low quality and it may have to change over time. The traditionalist assumption was that prolonged investment will continue to add value – it kinda does, but the return is ever diminishing. There’s a sweet-spot, where after a certain point you’re spending more time than the value you’re adding – that’s the time to stop!

The Agile architect

In the same article from Martin Fowler we cited at the start of this one, he goes on to define two types of architect. The first is described as:

The person who makes all the important decisions. The architect does this because a single mind is needed to ensure a system’s conceptual integrity, and perhaps because the architect doesn’t think that the team members are sufficiently skilled to make those decisions. Often, such decisions must be made early on so that everyone else has a plan to follow.

Fowler’s first description is often associated (though sometimes unfairly) with the traditional architect job titles, who sit above lowly developers, dictating their every move from their ivory towers. That doesn’t sound very Agile to me… In contrast, the second type is described as:

This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. When I see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain the technical consequences of some of their ideas in nontechnical terms – such as development costs.

This time, we have someone actively collaborating with the other members of their team. They have an awareness of the overall project and spend time working on high and low-level problems. They get their hands dirty when required, but are also able to communicate with anyone less technical. This person sounds like someone useful to have around – and could fit in to an Agile environment very well.

If you have someone producing a design in a silo, who does not spend time with the people who are building or requesting that change, then you have an ivory tower architect. In a nutshell, collaboration is the mark of an agile architect.

Pulling it together

  • Start with a simple design, because at the beginning, you won’t have enough of a design to support all the software.
  • Have a more and more robust design as the project goes on, because you can’t make progress with insufficient design.
  • Wind up with a fully robust design, capable of supporting the whole project and its future needs.

Source: http://ronjeffries.com/xprog/blog/context-my-foot/

From the point you embark upon your mission to deliver the Product Owner’s vision in an Agile way, you should be collaboratively refining your understanding about what is required. You then agree on their relative priority and begin thinking about the ways to implement those ideas. Early on, your team should have some idea about what the minimum viable product (MVP) might look like. From there, you need to start articulating how you are going to start building it.

With any complex problem, there is very rarely ever just one “right way” to solve it – and those solutions aren’t going to be perfect. There’s always going to be some form of trade-off, that cannot be avoided. A good architect should have enough experience to highlight where some of these trade-offs may occur (and what the potential impact could be). Armed with that information, what you should be doing is finding a solution that could work, then quickly proving whether or not it is going to be (just barely) good enough. Importantly, that means good enough for what your product needs to do now – not what it may need to do later.

To give you a related example, I once attended a talk given by George Berkowski about his book “How to Build a Billion Dollar App”. He described how a team had spent months of long hours and late nights to get an app finished and ready for its launch. After a huge push they got it finished and it launched – then no one downloaded it! At the time, he reflected that they could have just created a single page website instead, to see if anyone ever actually clicked the download link. If as it turned out, no one did, they could have saved a huge amount of time and money. This example was originally given to illustrate the need to prove a market demand for an idea, rather than any technical design concerns, but it transcends the business lesson.

If you identify that your application component really has to handle 1000 concurrent requests from day one, that will impact the architecture of your application. Just letting your team blindly hack away without any discussion is unlikely to be effective – but don’t be tempted to try to predict every bottleneck and point of contention either.

Instead, formulate a plan to prove your proposed initial design can handle those 1000 requests in an identified test scenario. Then, continue working together with the (embedded or prescriptive) developer, test and other roles – leveraging their expertise to bring that idea to life. If one way doesn’t work, fine – move on to the next solution candidate and continue working until you’ve satisfied your minimum acceptance criteria.

Remember that meeting the business acceptance criteria doesn’t necessarily mean the solution is good enough (as the focus is very often solely at the functional level). Your team may still be faced with some refactoring required to clean the code up to a maintainable state – or you might have some edge-cases or other functionality to implement. The important thing is the team has proven a solution for the current situation.

A huge benefit of this approach is that you’ll probably learn about several pinch-points and possible limitations along the way. Often this is information you would not have predicted in advance, but you are now left in a very good position – where you are better able to explain the consequences of any change introduced later. For example, if the Product Owner subsequently wanted to add more functionality to a key user journey, where the change may affect performance, you will have detailed knowledge of many of the likely bottlenecks.This knowledge is based on empirical evidence (from your work in that area), not a crystal ball. You can help the Product Owner accurately assess whether the value added from any changes are going to be worth the cost to develop going forward. That level of understanding is a great place for any product team to get to.

Agile team communication

Agile team communication

Encouraging good communication within a team is one of Agile’s key areas of success. From daily stand-ups to pair programming, refinement and retrospective meetings, working in an open and collaborative way is a core tenet of Agile, whichever framework or methodology you subscribe to.

No hierarchy?

Many Agile approaches attempt to instigate flat organisational structures, where everyone on a team is (theoretically) on equal terms. You’ll also encounter evangelists using somewhat counter-productive phrases, such as “no more managers” or “remove all hierarchy” or similar calls promoting the abolition of traditional reporting structures.

In reality, you’ll find that the world (and by extension, all our work) is inherently hierarchical. Even a typical Scrum team has an implicit hierarchy in the form of the Product Owner. Sure, they don’t manage the team in the traditional sense – and in more mature Agile teams, they won’t be dictating what is included in each sprint – but they do have some authority. They get to choose this feature over that, set work priorities, time-box development activity and more – they’re just not micro-managing the technical development.

Scrum of Scrums

When there is more than one team, one approach to coordinate their efforts is the Scrum of Scrums:

With this approach, each Scrum team proceeds as normal, but each team identifies one person who attends the Scrum of Scrums meeting to coordinate the work of multiple Scrum teams. These meetings are analogous to the daily Scrum meeting, but do not necessarily happen every day.

The team member from each team attending the Scrum of Scrums is generally known as the team’s “ambassador”. Interestingly, the role that attends this meeting is not fixed (it could be the Scrum Master, Product Owner or one of the technical contributors). This leaves three important issues:

  1. What is the agenda and knowledge of the attendee – business and technical roles often have conflicting priorities (and an Agile coach / Scrum Master may not understand either).
  2. When there is inevitably some conflict between teams (priority, dependencies, solution architecture etc.), who is ultimately responsible for making those decisions?
  3. Whose responsibility is it to maintain an overall product direction for the teams? What controls are in place to ensure the Scrum of Scrums team is able to reach a (consistent) consensus?

Network approach to communication

In Setchu, instead of using the Scrum of Scrums technique, it uses a predefined two-tier hierarchy. Multiple Agile feature teams are accountable to a single control team (made up of a Product Owner and Product Architect on equal standing):

Agile Programme
Network based communication.

Teams (and any member thereof) are strongly encouraged to communicate informally and often, in a network manner, between each other to resolve minor issues and dependencies. There’s no hierarchy between the feature teams, but they are expected to try to reach decisions both sides are comfortable with, for most day-to-day interactions. Whenever that’s not possible or when a discussion highlights a wider concern, the issue is bubbled up to their (mutual) control team:

bubbles

The control team is able to offer guidance and make decisions that are in the best interests of the overall product. As this team is a split between business and technical concerns, it is able to provide balanced solutions (and assess the wider impact) to their feature teams.

In this model, each team has clear ownership of its responsibility (and authority). When there is any ambiguity, there is a well-defined, central authority present to resolve the conflict – who are also ultimately accountable for the success of the product.

Managing technical debt

Managing technical debt

One common question I hear from teams new to Agile is “How do you manage technical debt?”. Agile is often blamed for producing more technical debt than more traditional approaches – whether or not that’s true, everyone should have a mechanism for tackling it.

What is technical debt?

For anyone unfamiliar with the term, very basically, technical debt is any underlying element of your software that you should rework at some point in the future. Usually as a result of a previous decision or (in)activity that will impact the long-term value of your product, if left unaddressed.

It differs from a change initiated by the business in that it will usually be something either imperceptible to anyone non-technical and / or not involved in the technical implementation of the product (or certainly not obvious).

Ward Cunningham, credited with coining the term, describes this concept in the following way:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

He refers to object-oriented programming, but you’ll appreciate the concept applies universally, regardless of paradigm.

Unplanned technical debt

Unplanned technical debt is usually the consequence of external change, time pressures or a lack of understanding.

For example, maybe you produced a service that made heavy use of a rate-limited external API, on the assumption that your expected traffic volumes would never approach close to that value. Then, your product is a runaway success and you end up with more traffic than the rate limit allows, degrading performance.

Another example could be that your project made use of a UI library to produce your website, but now there are newer browser versions that the library does not handle, breaking layout and functionality in modern browsers.

You may have written an inefficient search algorithm, as you had to produce something very quickly at the time – but with further optimisation you could save significant server resources, needed for other processes going forwards.

From personal experience, I’ve had situations where I’ve discovered a much more elegant solution to a problem after the fact (where refactoring would improve pace of change and customer experience), towards the end of a project.

Planned technical debt

Sometimes you just have to accept that being able to produce something fast is occasionally better than (pro-actively) spending additional time on quality. For example, it’s quite valid to attempt to prove a concept in the quickest way possible, usually to answer an unknown factor (“will this work?”), over longer-term concerns.

This could result in things like a conscious decision not to include logging or perhaps you chose to skip adding any build automation, knowing that they would both be useful longer term. The key points with this approach is that the team has agreed the priorities, potential impact and any mitigation up front – the consequences of the situation are understood. As long as you address the issue later (or make a conscious decision to live with the issue), based on the business value balance, that’s fine.

When planned technical debt becomes particularly unhealthy, is when it emerges from a pressured, one-sided source – instead of as a natural result of collaborative effort. In Agile teams, this is usually the result of a dictatorial (bad) Product Owner – or someone else able to pressure the team into focusing on non-technical priorities, over the team’s overall agreed priorities. You could argue this is actually unplanned debt – but that divorces the responsibility from the stakeholders, who ultimately need to acknowledge that they have chosen this path.

The danger here is that the potential consequences of this type of technical debt are not understood. That’s a risky place to be – unbounded problems have a tendency to spread quickly – akin to spending on a credit card with no limit (and no one ever checking the balance). If your technical debt exceeds the value of the product, you’ve failed.

Balancing value

Successful software projects eventually need to achieve a level of balance between business functionality and technical architecture.

Too much focus on either side is not good. Businesses tend to focus on tactile features over practicality, while development teams want to produce academically elegant solutions that no one may actually want (or simply spend more time on it than the business value justifies).

Regardless on the cause of the debt, the way you tackle technical debt is largely the same. The team needs to prioritise effort together.

If your backlog refinement meetings are genuinely collaborative then you’d ideally have discussed and agreed your prioritisation of work to include a balance of business and technical needs – minimising debt in the first place.

While that may be the ideal, striking that balance isn’t always very successful, for a variety of reasons. Additionally, unplanned technical debt is a constant unseen threat – and it can build up at any time, even with the best of intentions.

Newly discovered technical debt should be bubbled-up (flagged) so that it can be addressed by the team. This means adding a story to the backlog with a description of the problem and optionally including a proposal to resolve it. When your backlog refinement meeting (grooming) occurs, you should have a mechanism to trigger triage of new stories, prompting a discussion about the issue. From there, your technical debt becomes like any other story being groomed:

  • Flesh out the requirement – is it a problem?
  • Break down any large chunks into smaller, manageable activities.
  • Agree the acceptance criteria for it to be considered resolved (done).
  • Prioritise based on the value to the product / feature.
  • Add the stories to the appropriate sprint backlog.
  • Review your balance of priorities again at the next planning session.

That’s it – when you become aware of technical debt, flag it by creating a story to represent it, let the team decide when and how it needs to be tackled – then deliver on your commitment.