A Tale of Two Architects

Ever got caught up in a debate about up front architecture versus evolutionary architecture? I know I have, but which is right? I believe it all depends on the business context and the information you have available.

I my mind both approaches are valid, just generally not on the same set of problems. Deciding which architectural approach to take should be considered seriously, and if you’re not having a long hard think about which approach to take, you probably should be.

This post hopes to equip you with some basic ideas to have a meaningful conversation about how you should approach your project from an architectural point of view: whether it’s the design it before you code it approach, or quickly start on the implementation and use learning to feedback on the direction you should be heading.

I’m going to split the approaches to architecture into the following two broad types:

Architecture Approach A

The first approach to architecture involves a lot of planning and discussion and a general effort to deeply understand the problem and map out the system up front. Typically there will be a person or delegation of people responsible for the architecture as a primary role. A separate team responsible for software implementation will build against the architectural vision. It will generally involve lot of meetings and documentation.

Architecture Approach B

The second approach is to transfer the responsibility of architecture to the implementation team and allow them to grow the architecture organically based on the continued learning and insight gained during the build and feedback from stakeholders as they see the software evolve.

The Winning Architectural Approach

I believe both approaches will get there in the end with a determined team (so by simply delivering a project using an approach, you don’t necessarily have proof about whether the choice was right, only that you have a good team), however, I think there are clear cases when one approach is better than the other.

The Architect Who Faces Certainty

An architect that faces certainty usually works in a business whose landscape is unlikely to change and with users and customers that have clear expectations and have requirements that are highly predictable. This is a clear choice for Architectural Approach A – the Certain Approach.

The Architect Who Faces Uncertainty

An architect that faces uncertainty will work in a business environment with a volatile market and whimsical users/customers whose needs are unpredictable. This is a clear choice for Architectural Approach B – the Uncertain Approach.

The Future of Architecture

Choosing the right architectural approach really depends on how much information you have about the future. If you have certainty, making all your decisions up front will get your project where it needs to be efficiently as everything can be mapped out. If you do not have certainty, you need an evolutionary approach to architecture based on gathering the information you need for the next set of decisions. Typically information is gathered by implementing part of your architecture and extracting insight from real results.

If the time taken to plan is spiralling out of control and conversations involve a lot of “what if this happened in the future” and you are hedging your design against uncertainty you are probably trying to up front plan against uncertainty – a sure sign you need to rethink your approach.

Another way of looking at the two approaches is from a scientific point of view. When trying to model something we understand it’s easy to come up with sound model. When modelling something we don’t understand, we must experiment in order to piece the model together.

As computing power continues to increase, and software tools become more powerful, it’s becoming harder and harder to model the systems that our tools are capable of building and predict how users/customers will use them. Companies should be comfortable with both architectural approaches to ensure the best chance of success developing software.

Designing software at the start of a project in a certain world is well understood, and I don’t think there is much more to teach anyone about how to do it well. Evolutionary architecture is a seldom discussed topic in software literature and their are similar sounding labels for other ideas. To feel your way through a project implementing the right parts at the right time to get the right feedback is tough and ultimately an art form with much scope for new thought but already used with great success. I believe it is vital to invest time in exploring the benefits that evolutionary architecture can bring to delivering large scale customer facing web platforms that inherently have many unknowns without being paralysed by the fear of implementation without certainty.

Whatever you decide, uncertainty will be your guide 🙂

Going backwards is sometimes the only way to go forwards

I was recently drafted in as Project Manager on a redesign project for one of our clients. The project had been underway for several weeks, the team were all very busy, the ‘work in progress’ boards showed that lots was being worked on but the ‘accepted’ and ‘live’ parts of the board were worryingly empty. There was a project plan but it was clear the team weren’t delivering against it.

I observed what was happening in the team over the course of the next week or so whilst trying to get my head round the requirements. The team were doing daily stand-ups reporting in on what they were working on, everyone seemed to be working on unconnected component level user stories.

The team were complaining about the designs, they were inconsistent, kept changing, looked OK for print but wouldn’t work for the web, didn’t work if the content (which was content managed) got longer etc. etc. etc.

Many stories had been started but couldn’t be finished because they were blocked for one reason or another. If the team got blocked, they just started something else.

The team were demoralised, they weren’t getting any sense of progress, couldn’t see the big picture and nobody was doing anything about their frustrations.

One day I asked a question about how we were going to put the redesigned site live. The customer was going to need to do some content population in the live CMS so we would need to let them do that without the risk of the new pages going live before the client was ready. Some of the content on the existing site was going to be re-used but would need to be available in the new designs. Stakeholders would want to be able to see and approve the new site before it went live but this categorically couldn’t be on a URL that just anyone could access – even within the organisation concerned access to the new site would need to be restricted.

When I asked the question everyone in the room looked blank, the team hadn’t thought about this, nobody had asked the question before and there were no ideas.

So we stopped. Mad as it sounds, on a project which was running behind time, running over budget and with nothing actually delivered we decided to stop work. Anything we did was pointless, we weren’t getting anything accepted or live and we had no plan for getting things live.

We don’t like to deliver bad news, but if we have bad news we don’t try and hide it and we deliver it early. We called the customer, we told them we had a problem, we said we were behind plan and that we were going to stop and re-think the approach. Understandably they were concerned, they were adamant that the dates we had given them weren’t moveable, they said they didn’t want to have another call like that again and that they wanted us to update them when we had a new plan.

The senior developer and I then got together and talked about the problem. We took a fresh look at what we needed to deliver and simply printed out in colour all the pages we needed to build. Whilst our backlog of component level stories looked scarily unachievable, the number of pages we needed to build looked far less daunting.

We had a team of 3 developers on the project. All we needed to do was a page a day between the three developers and we’d still have 2 weeks before the go live date for amends, launch plan and as contingency. Was a page a day feasible or should we ask each developer to produce one page each every 3 days? We talked about the strengths of the team – one of the team was a whizz at HTML/CSS, another had a lot of Sitecore backend experience, another was a good all-rounder.

The Senior Developer bought the other developers into the room and put the ‘page a day’ challenge to them. They agreed they’d all prefer to work together, doing the things they were each best at and they were happy to commit to doing a page a day with a ‘we don’t go home unless we’ve met our goal’ attitude. They were fired up, they had something tangible to aim for, it would be really easy for them to know if they’d achieved what they wanted to.

My job as the Project Manager having got that commitment from the team was to make their jobs as easy as possible – clearing the path ahead of them.

I talked to the client about the inconsistencies in the designs and we consolidated a number of the components which were similar thereby reducing the work that was needed (and producing a better user experience). I asked the designer for an updated style guide confirming which fonts, colours, buttons should be used where and when.  We agreed the style guide was the definitive version of what we should follow even if the Photoshop files we had didn’t.  Before we started work on any page I suggested that we’d do a final sanity check that we were working to a confirmed/signed off design to minimise changes later.

We agreed that any ‘changes’ after delivery would be added to a backlog which we wouldn’t look at until after all the main work was done. We’d then prioritise the changes and decide which were ‘must have’ for launch and get as far down them as we could. If there were more ‘must have’ changes than there was time available the client accepted the fact the date would need to slip but that the slippage would be down to the organisational wants/needs and not our inability to deliver what we’d committed to.

We told the client that we wouldn’t start any story that we weren’t confident we could finish and get approval on. We set the client expectations about the time/effort this would require on their part and got their commitment to make the relevant people available on the right days to sign off the work.

We agreed that getting a page ‘done’ for the customer to sign off was getting it all the way through to a live environment and onto a URL to which we could restrict access. This required a change to the architectural approach and we had to spend several days unpicking and re-doing some work we’d already done. But it was absolutely necessary.

Our new plan and approach massively de-risked the launch of the new site. Code was going to be deployed up to live every day. Those that had access would be able to see the site coming together on the live servers, they could update content on the old site and see it in the new designs, they could add new content. In short on go live day, all we needed to do was a configuration change to point the site URL at the new site we’d created – no downtime for the end users or for the content editors.

With renewed vigour the team jumped on the new plan. We stuck those printed out designs on the wall in ‘to do’, ‘doing’ ‘done’ columns and every day those designs would move across the columns and we’d see the progress. The increased production with the team working together rather than independently was amazing to see. If one person finished their piece of the jigsaw early they’d help someone else out. Every day they were doing a new page, some days they did 1.5 or 2 pages.

Daily stand-ups became unnecessary, the team were working so closely together with the same daily goal that they were communicating non-stop all day across the desks. I didn’t need to ask whether they were on track or how they were doing – I could see and hear it.  The client didn’t need updated project plans or status reports – the teams progress was visible every day by the release of something new.

The team delivered the site on time and under budget. The client was able to use the spare budget to include some changes and new features they wanted. The launch day was as smooth a transition as anticipated, literally a push button exercise to switch the new site over. The client was over the moon. The team were buzzing and had a real sense of ownership and pride in the end result.

It was a real team effort and a project I thoroughly enjoyed working on (even at the most stressful times) with a great team of committed professionals (you know who you are).

Here’s what we/I learnt:
• Spend enough time planning up front – don’t be tempted to dive straight in to the work
• Don’t assume every project or piece of work is the same and that processes which have worked before will work again – look at each challenge with a fresh pair of eyes
• The power of a team is far greater than the sum of the individuals – play to your strengths
• Think about getting things live early and how you’ll launch – de-risk big bang launches
• Don’t start what you can’t finish
• Tackle impediments and issues, head-on (frustrations and moans often hide an impediment)
• If it’s not working don’t be afraid to stop and rip up the rulebook
• Find a way to see your progress – nothing gives a greater sense of achievement
• A problem shared is a problem halved – getting the team ideas and commitment is better than telling them what to do and making the commitment for them

Work, Rework and Maintenance in Software

I thought it would be worth clarifying the terminology used to express the different types of work, rework and maintenance in software development.


Refactoring is the art of making your code clean and refining the design in small incremental steps towards the SOLID principles of software development. Refactoring should be performed many times a day to ensure code is clean.


In order to learn enough about a problem, a prototype is often built that will be thrown away. If the prototype is not thrown away, it is not a prototype. Prototyping should be used to gain knowledge and understanding of a problem. A prototype will generally have a substandard design because the problem is not well understood until the prototype is finished. That’s why you throw a prototype away and redesign what you have just done with increased knowledge. Don’t continue working on a prototype when there is no more learning taking place. Do not mix user interface prototyping with software design prototyping. Always keep the two separate.

Tracer Bullet

A tracer bullet is an implementation of part of a piece of software. A tracer bullet is used to learn enough about the larger piece of software, usually in order to inform estimates and tackle technical risks early. Tracer bullets are risk management for developers. A tracer bullet is only finished if the code is production ready, tested and has been kept clean by constantly refactoring the code during development otherwise it is a prototype and should be thrown away.


Redesign is usually undertaken when existing code needs to be drastically remodeled. Redesign is an indication of one or more of the following problems:

  • the code is not clean and does not following the SOLID principles
  • there was inadequate knowledge during development
  • the project was rushed
  • technical risks were not properly flushed out

Redesign is caused by a lack of refactoring, prototyping and tracer bullets.


Every project should have a healthy mix of prototyping to inform design, tracer bullets to inform estimates and reduce risks and refactoring that should be done regularly throughout the day. Redesign implies that you’ve got an unhealthy mix or are ignoring important steps in the software development cycle.

Also, changes to requirements would potentially precipitate one or more of refactoring, prototyping, tracer bullets, or even redesign. The later suggesting quite a major change.

Dealing with conflict – establishing the ground rules

Note: This blog post is a work in progress, it explains where we’ve come from and where we’re currently at and we will update this post in the future with what we’ve learned.

As a management team here at True Clarity we’d all read Patrick Lencioni’s ‘Five Dysfunctions of a Team’ and felt we’d spent a good deal of time building up trust within our team and felt confident we had no fear of conflict.

Our meetings certainly never felt devoid of conflict – there was often passionate debate and raised voices but was it really healthy or were we displaying the classic signs of artificial harmony?

We were seeing signs of ‘passive aggression for example team members not saying what they really felt (either agreement or dissent), ‘forgetting’ to do things the team  they had committed to do, ‘blaming’ of other people or teams for our problems and a general lack of anger or frustration being exhibited.

There were areas that there seemed to be an unwritten rule about which were ‘off topic’ for discussion especially if they related to an area of the business individual team members felt responsibility for or felt were someone elses responsibility.

In order to address this we had a Management Team ‘Mastering Conflict’ meeting last week and decided we needed to just have a frank, open discussion about our understanding of conflict and what we were comfortable with.  After everyone had had their say we drew up a set of ‘Conflict Rules’.

Management Team Conflict Rules

We hold each other accountable for:

  1. The basics (being on time for meetings, no mobile phones or laptops)
  2. Staying results (outcome) focussed
    • Not rambling
    • Keeping on topic etc.
  3. Be Kind
    • No shouting
    • No pulling faces or other non-verbal stuff
    • Don’t talk over people
    • No bitching (observations only)
    • Refrain from banter in meetings (meetings should be professional and formal environments)
  4. No hats (explicitly only) (This means that whilst we may have different roles e.g. company directors, heads of departments that when in these meetings we act for the needs of the many/group goals not our individual goals)
  5. Getting Naked (See Patrick Lencioni)
  6. Everyone gets to talk and listen

Time will tell whether we are able to hold each other accountable to these rules and call each other out if we break them.  Early indicators are that this is not easy and definitely something we need to practice!

Update 10th May – Anecdotes & Tolerance

So how are we going following our conflict rules.  Well we’re all learning to communicate better with each other.

We have found that sometimes people are unable to express themselves clearly in a meeting or are unwilling to pitch in, particularly if things are getting heated.  We have found that writing anecdotes in the third person and making those visible have made it easier for people to say how they feel or what they think in a more considered way which is a good way to open up a dialogue.  We hope that in time these won’t be necessary and we’ll have evolved as a team to an extent where we can say anything at any time.

We have recognised a need for tolerance in the team.  It’s important for us to catch an emotional response in ones self as a sign the other person is trying to communicate better. We need to focus on what is trying to be said (with best intentions) and not try and assume someone is saying one thing and meaning another.

We need to be able to notice fear in the team.  Fear of people disengaging if someone says the wrong thing. or fear of the angry “shout down” if they say the wrong thing.  However recognise we all need to be able to “say the wrong thing” so we can learn to communicate better.  Not saying what you feel/think won’t help the team learn.  We hold ourselves accountable for being honest.

The 7 types of customer value

How can a team of people, who’s only real tangible output is working software, create value for their customers?

Let’s start by giving our question some context. Our team of people, already have working software and customers. Within the team we have all the skills required to write, test and deploy code. The team handle the entire lifecycle of the working software, from birth to death. They talk directly to the customers. However for the sake of this post I’d like to treat the internal workings of the team as a black box. I’ll let your assumptions about what a software development team look likes fill that gap.

Our starting point is to consider seven basic types of customer value. The list is ordered in such a way that items on the right give you more leverage for value creation. However it is assumed a healthy team will balance delivery across all types, and know when to approach each type of work.

1. Information

This work involves no coding activities; the team provides the customer with information about how the software works. This type of work is about increasing the value-in-use of the currently working software.

2. Incident

Very few examples of working software these days does not involve some connection to servers. When there is a problem with these servers then things need dealing with quickly. The value to the customer is measured in the speed of the response.

3. Increment

An increment to the working software, often called a new feature or function, creates value by allowing the customers to do new things with the existing software. Since this new feature is based on speculation about what will work, the value may not be delivered, it is therefore considered less valuable than improvement type work. Removal of functionality would also fit in this category.

4. Improvement

Based on direct customer feedback, the team make small, evolutionary changes to the working software. Again this work increases the value-in-use of the current working software, but critically it is based on the experience of the customer using the working software.

5. Investigation

This experimental work requires a scientific approach and an appetite for failure. The value for the customer is the knowledge gained.

6. Impact

Rather than focus on the software, this type of work is based around a customer goal. It will often be related to a business deadline. A Minimum Viable Product would fit neatly in this category. Any measures of success would be based on business metrics.

7. Innovation

The team is able to take an idea related to the customers’ business and create new needs and wants. This is similar type of activity to a Lean Start-up Pivot. This is about doing something different rather than better.

There are two ways of super charging the customer value you create with each type of work. The first is for the team to stop order taking, and go find the problems for the customer. This pro-active approach works with all types listed above, a team that goes and hunts out these value creating opportunities will always beat a team who waits for the orders to roll in. The second way of increasing the value creating potential of the work is for the team to shift its focus away from software only, and move into working with the entire business system. This approach calls for the team to embrace the customer as a member of the team, so they can work together on making changes to the wider organisation or system in which the customer operates.



Context Switching

The dreaded context switch. I hear about it all the time. I have to drop what I’m doing several times a day to listen to people discuss it (chuckle). Jokes aside, I’m genuinely interested in the reasons why people want to avoid switching context.

Up until very recently I was convinced context switching was a bad idea. I would also have assumed any books that deal with context switching would justify my belief Q.E.D. style, case closed. I’ve been wondering lately if my thinking is broken and that I’ve been fighting for the wrong cause.

So what is context switching? In my world we are talking about changing from one deep train of thought to another. As a developer it takes me a while to get my head round the code I’m looking at. If I have to break my concentration, clear my registers and push what I was thinking about onto my mental stack for later, it takes times. A familiar example would be working on the code for a project and an urgent problem comes in that requires my attention to be diverted to the codebase for another project. Everything I was holding in my head about the code I’m currently working on gets lost forever as I bring my thoughts to bear on a different problem.

Now I’m sure you might be thinking there are also sorts of time management practices you could apply to handle this. However, I would urge you to think twice about how you tackle context switching. Is it really a good idea to rush into this problem with your productivity hat on and try to optimize the process to avoid context switching? If you do, much simpler and more important questions may go unanswered: are people finding context switching hard? If they are: why is that?

Recently I read two very different books. Although they turned out not to be so different after I’d read them. One was on psychology, the other development.

The book on psychology “Think Fast, Think Slow” discusses how we handle the process of decision making and problem solving. It will come as no surprise that we need to engage a large percentage of our brain to solve problems. The harder the problem the more time and thought you will need to understand the problem and resolve it. My take away is that there are types of work that we struggle with. We’ve all put a book down because it was just too damn complicated. We’ve all read a book where each page was jammed so full of information it took ages to read. I’ve also read similar sized books in a few hours. Those books I’ve read quickly were just… well, less complicated!

The book on software development was called “Clean Coder”. It challenged some of my long held beliefs about good software development. It especially challenged how I think about being in the zone. I love being in the zone. I love being so engrossed in difficult problems that hours seem like minutes. I love holding hundreds of lines of code in my head trying to figure out where it’s going wrong. I’ve woken in the morning knowing how to fix a bug in some thousands lines of assembler I’ve memorized. It’s addictive and gratifying. There can be a certain amount of bravados about being better at handle complicated problems than others. Is boasting about fixing really hard code like totally unreadable assembler a good thing? Is being so engrossed in a problem that you lose sight of the big picture the best approach?

Both these books were telling me something about complicated work. It can be difficult to get your head round. We don’t want to be disturbed when we’re engrossed in complicated work because it’s difficult to get engrossed. If you like a challenge, it can be a lot of fun. We don’t want to be disturbed when we’re engrossed in complicated work because we’re enjoying ourselves. Whether context switching is time consuming or a killjoy, the fact is: difficult challenging work is time consuming.

If context switching is a problem, you need to understand if the work is the underlying cause.

Maybe you’re thinking: “Duh? Of course software development is hard. We need to focus more and have less distractions to deal with it!”

Maybe you’re thinking: “I kind of get it, but we can’t make the work less complicated, we have no control over the work coming in!”

Maybe you’re thinking: “How can I make the code I have to read all day simpler and clearer?” If you’re thinking about the possibility of making things simpler, you understand.

Organising Your Backlog

As a Product Owner one of my key responsibilities is ensuring that backlog items are worked on in the correct priority order. This is far more difficult than it sounds, as most clients have priorities that rapidly change along with the needs of the business. To help deal with this, I have always used the Kano Model as a guide for helping clients understand what priority should be given to an item of functionality.

The Kano model essentially breaks down requirements into three sections; ‘must haves’, ‘should haves’ and ‘could haves’.

‘Must have’ requirements

These are requirements that must be in place for clients to be able to use the product at its most basic level. For example if we were building a word processer, the ability to save or print work might be considered ‘must have’ functionality. Without these basic requirements, the project will not achieve the base level of acceptance by clients and will not be used by them, regardless of how many ‘should’ or ‘could have’ requirements are added.

‘Should have’ requirements

These requirements provide additional client satisfaction proportional to the amount of functionality added. Put simply, the more ‘should have’ requirements there are the more satisfied the client will be. With these requirements, there is a neutral satisfaction point prior to which clients will not be satisfied. This point will vary from product to product and is the average expected level for the product. Using our example of the word processor, it can be considered that changing font size and type or adding images to a document are examples of ‘should have’ requirements.

‘Could have’ requirements

Once a product has satisfied the must have requirements and sufficient ‘should have’ requirements to satisfy clients, attentions can be turned to requirements that ‘could’ be added to the product. These are traditionally requirements that set the product or service apart from the competition and are where most innovation lies. They add the ‘ooo’ factor to a product. Drag and drop functionality could be considered a recent ‘could have’ requirement.

A note of warning; as time passes, functionality will move from the ‘could have’ pot into the ‘should have’ pot and then from the ‘should have’ pot into the ‘must have’ pot. For example, a spell checker would once have been an exciting, innovative, ‘could have’ requirement. Nowadays it would be considered as a must have for any word processing product.

Take clients through the backlog

By taking clients through the backlog and putting stories into these groups, it is far easier to prioritise important functionality over and above work that may not affect the success of a project. Some clients may struggle at first to break stories down into these groups (“but it’s all necessary!”). When going through this process, I tend to use a tried and tested (also extreme) formula; whenever a client is unsure where a story should sit in the backlog, I ask;

“If the team were to be killed in a car crash/ hit by a meteor, drowned by a tidal wave (pick your favourite) at THIS point in time (specify a point in the backlog), would the product be in the best position possible?”

If not, reorganise the backlog as required.

This process should be repeated every so often (more often for those backlogs that change regularly) to ensure that the backlog is still appropriately prioritised. Hopefully, you will find that you work on the important tasks first and leave those sudden whims of the client until later in the project. This way, if you do run out of budget or time, the product will be in the best shape possible.

How an Agile environment can make testing more effective

As a tester I take great pride in knowing the work I do contributes to a client getting what they want. Yes you heard that right WHAT A CLIENT WANTS! Not what a long drawn out technical specification tells me they want, but actually what they want and need from their product. Is it really that hard to ask a client this simple question?

As a tester in a waterfall environment one of the most laborious and soul destroying tasks was writing the dreaded test script! Spending hours trawling through huge technical specifications and planning test routes, picking out holes in requirements, then spending days on end writing the script only to find you have to constantly have to re-write and update it. Then you still have to run all the tests! With all of this to do and deadlines looming you can see how QA always appears as a bottleneck in the development lifecycle.

“One small change” in a product can mean hours of re-work for something that is fundamentally quite small. In a waterfall environment the word “Change” sends shivers down a tester’s spine and is always met with resistance with the usual comeback of “That’s not what the spec says” as the tester knows this “One small change” always leads to huge amounts of work, updating scripts and regression testing. Why are testers so adverse to change as we are here to make sure the client gets what they want?

The reason behind this is we don’t like wasting our time as we always have deadline pressures being last in the chain. So how can a tester be more efficient and respond to change easily and ensure your client is happy? It’s pretty obvious that the easier it is to adapt to change and the more time testers spend actually testing the product, the better the quality of the product. The better quality product that meets the expectations of the client leads to you guessed it…… happier clients. So how can testers spend more time testing and adapting to change without missing deadlines? Be Agile and Innovative!

Ask yourself “WHAT IS MORE VALUABLE TO THE CUSTOMER?”, a product that has been thoroughly tested in all manner of scenarios and provides the customer with the functionality they require or a product that has been tested following a rigid test plan but does not fit the requirements of the user because you have not been able to adapt to changes that they require?

So how does an Agile approach help testers be more adaptive to change? Agile has provided a great platform for testers by providing them with a constant workflow of iterative chunks, these chunks can be thoroughly tested in isolation quickly and efficiently. Using an Agile approach, continuous feedback allows us to test little and often, making change simple and cost effective. By the time the work goes to UAT for final acceptance with the customer, most feedback has already been dealt with which mostly results in a simple confirmation of acceptance criteria. This provides QA a real opportunity to understand early on in the project the client needs and expectations and build a valuable relationship with the client which is crucial to the success of a project.

Using tools within an Agile environment to be more efficient is an excellent way to increase the team’s effectiveness and reduce the “QA bottleneck”. By working smarter you can relieve the test script burden. I am not saying you have to abandon test scripts they do have value in their own right as they provide anyone who cares to read them an insight into how the product should work and provide detailed information on legacy products, but you can be smart with how you document! For example creating automated test scripts that cover your essential tests provides anyone an insight into how the product should behave, but this script has more merit than a standard manual test script. So how does this magical time saving test script get created so quickly and easily? Adding automated tests to your script is not a long and boring task as it can be recorded whilst you are testing a new iterative chunk of functionality, as each iterative chunk is delivered to QA your script keeps evolving as each iteration passes until you have a fully automated regression script! Finally a document that actually helps people rather than hinders!

These simple changes make the life of a tester much more productive, reduces waste of resource by not having to sit around waiting for builds! It also provides better overall quality and happier clients. Not to mention make the life of a tester much more enjoyable and less stressful.

What Do ScrumMasters Do Again?

In my time working with agile, I’ve heard ScrumMasters described as many things:

  • ScrumMasters are secretaries to the development team, doing the things the developers don’t have time for
  • ScrumMasters are Project Managers
  • ScrumMasters act between the team and the Product Owner
  • ScrumMasters are an arbiter
  • ScrumMasters are responsible for chasing customers
To be fair, I think the title ‘ScrumMaster’ itself is a little misleading. The word ‘Master’ conjures up images of authority and expertise that I don’t believe are a fair representation of the role. The amount of times I’ve heard ScrumMasters represented as ‘waste’ in agile in scary. Hearing comments such as ‘I would never pay somebody to do this role full time’ just makes me wonder what experiences people have had with ScrumMasters and how much these companies invest in continuous improvement which I hope you’d agree is essential for longevity of any business.

“A system cannot understand itself. The transformation requires a view from outside.”–W. Edwards Deming, The New EconomicsA system cannot understand itself. The transformation requires a view from outside.

How do you know you’ve got a sticky-note on your back marked ‘Kick-me’ without someone pointing it out (or stumbling across a mirror)? Interactions between team members are similar, and according to Deming’s statement, cannot be understood from inside the team.

A ScrumMaster is like a football coach, standing on the side-lines during the game. A football coach doesn’t play a position but they are constantly looking at how the team are interacting with each other. They know if the defensive line is being held too high and how the team aren’t working together to achieve a common vision. After the game the coach helps the team look at their performance for strengths and weaknesses, they’ll identify actions for potential changes and implement them incrementally to avoid boiling frog syndrome. Although a football team may be able to play 1 or 2 games without a coach, other teams may eventually overtake them in ability and effectiveness. Does this sound familiar?

Describing what a ScrumMaster does every day is hard to describe because every team is different. As I’ve changed from team to team over the years my activities and levels of involvement vary depending on what constraintis holding the team back from increasing their effectiveness. This may be anything, from the obvious impediments like the team not chasing feedback from a Product Owner/Customer, right through to the team feeling demotivated when senior management impose a well-meant but miscalculated delivery of the latest process initiative. In Agile Development, we’ve moved away from requirements documents to value people over processes. We know the value of a powerful vision over detailed requirements when developing software. Why should our jobs be any different? I can’t remember the last time a job description actually described what I did every day. Instead of a Job Description why not buy into a Job Vision? A powerful and ambitious statement that inspires us to do our job well?

As ScrumMaster I am striving to make myself redundant.

Yes, I really mean it. In my opinion, a ScrumMaster or Agile Coach for a team should be striving to put themselves out of work. You’ll never get there of course but that doesn’t make it any less important to try. We should be identifying constraints and impediments to the team becoming self-organising (not necessarily self-directing – future blog post on this one perhaps?). This doesn’t mean chasing the Product Owner/Customer or writing code for them when the team are busy, why are they so busy? Why couldn’t they write the code themselves? As soon as you put yourself in the system you lose the ability to understand the system.

So what’s the Vision for your role in the company? I’d be especially interested to hear ideas on vision statements for Product Owners.