Ways and Means committee

Ways and Means committee

The inaugural meeting of the Ways and Means committee convened at ThoughtWorks Werkstatt Berlin on the 31st of March. This first event of the committed brought together tech industry people from all over Europe. Hosted and conceived by Dmytri Kleiner and Dino Frese from ThoughtWorks, the Ways and Means committee is a group that aims to help tech leaders share experiences, discuss problems and cultivate a network of a trusted peers with which to seek advise.

This meeting asked the question “Why do sprints fail and what can we do about it?”. We were not looking to solve the industrys problems in a single session, but really, to see what kind of things that, as tech leaders, are within our power to influence.

After an introduction presentation from Dennis Traub from ThoughtWorks and a conversation starter from Mike Pearce from MOO.com, the session broke into groups to brainstorm just why sprints do fail. The teams jotted down ideas on post-it notes with no filtering, trying to capture the behaviours or conditions required for sprints to fail. Once that was done, we grouped similar post-its toeether and identified the following themes as being categorical causes of failing sprints:

  • Stakeholder expectation management
    • Some examples of these kind of issues were stakeholder patience, predictability issues, lack of transparency, bad requirements and stakeholder mandated solutions
  • Team Culture
    • Picking the “easy” bits of “agile”. The inspect and adapt loo is missing. People are “convinved” to commit to too much work.
  • Bugs and Fires
    • Business as usual will always be a fact of life, how do we deal with these kind of things without losing momentum on what really counts.
  • Process as ritual
    • When you decide what to do, you decide how you’re going to do it. But many become slaves to what is laid down as process – unquestioningly following it without really understanding why. The backlog becomes a theological debate, velocity is the only truth of progress etc.
  • Purpose/vision/Focus
    • Why do we do what we do? What is driving is to build these particular feature? Lack of understanding around what the purpose

Given we had three teams and limited time, we dot-voted on which were the themes that we’d most like to discuss further. These were “Stakeholder expecatation and management”, “Team Culture” and “Process as Ritual”. We agreed that our goal, like the original Agile Manifesto, was to come up with a set of principles that could guide a team when coming up against any of the above problems. As we weren’t able to solve for every issue that we had recorded (and frankly, wouldn’t be able to) principles were a better way of providing broad guidance for a multitude of sins without being too perscriptive.

So, after some lengthy debate, these were the principles that we created.

  • Stakeholder expectation management
    • Values and Metrics: Meet a business value over showing productivity.
    • Transparency and Dependencies: Transparency over commitment
    • Milestones and continuity: Goals over features
    • Goals and business value over showing productivity and finishing features.
  • Process as ritual
    • Question the process
    • Don’t be a backlog pack-rat (don’t keep every story for the sake of theology)
  • Team culture
    • Agile has to be cultural (not from a scrum manual)
    • Culture starts small. Build organically, infect and contage.
    • Hire to cultural fit
    • Teams should look at their own balance of culture, but needs to work bottom-up-top-down.

We closed the session with a mini-retrospective on how we should continue with the Ways and Means committee, the general consensus was that it should be a little longer, less warmup and more discussion and that we should communicate by way of a mailing list.

BDD: Starting With Quality

By Shannon Kringen @ flickr
Quality with a star and stuff

Quality isn’t defined by a lack of defects or bugs. You wouldn’t get a cup of barista coffee and exclaim, “This coffee is quality because it doesn’t have a problem with it.” (No bugs in my coffee). You can get a cup of coffee from a petrol station that doesn’t have any problems with it. It’ll be hot, wet and coffee flavoured – there are no defects with this coffee. So, where does this idea of the “quality” of something come from? It’s a subjective thing. A quality cup of coffee to me may not be the same quality cup of coffee to you. If you favour a black americano, your definition of quality is not going to involve a milky heart drawn into the top of it, which is how I like my coffee.

When we talk about the quality of a feature, the fact that it doesn’t have any defects is an implicit part of that quality, but it’s not where quality starts or stops. What makes the quality of a feature is whether or not it does what it’s supposed to do and whether it provides the amount of value to the user that they expect. Again, this is different depending on your context: what you application does, who it does it for and why.

Quality Assurance (QA) plays a fairly key role in any software development team. I know some schools of thought suggest that there shouldn’t be a QA role, and while this is probably the subject of a separate blog post, I feel that this is wrong. We have a QA in the team, just the same as we have a designer in the team. It’s a specialist role that requires certain skills I don’t expect engineers to necessarily have.

That said, I’ve always been troubled with the way that the QA role is executed in a team. Let’s suppose that we’ve got a scrum team that performs well. They commit to a given number of independent stories, work on them sequentially, so they finish the first story before starting the second and so on. Once the feature has been completed, the work of the QA starts in earnest (until that point, the QA will put together a test execution plan and a strategy for dealing with the tests during the sprint). They will begin exploratory testing and creating or updating automated tests. This is all well and good and will ensure that the feature meets the minimum, implied, level of quality. In most cases, it’s enough that it’s free of defects.

For me, this is where the problem lies. But how do we solve the problem?

We realised that actually, we never really discussed what quality meant to a particular story or sprint. We had made assumptions about the quality based on the content of the story and the acceptance criteria. As long as the story met those acceptance criteria and didn’t have any defects, we assumed we were done. In reality, we weren’t really thinking about what constitutes quality but just what constitutes the feature.

So we decided to start with quality. It made sense to talk about what we thought quality meant to any particular story before we talked about anything else. At the beginning of planning a story in sprint planning, we would spend some time discussing what quality meant to this feature. Using the example of a login screen, the story might be:

  • As a user,
  • I need to log in to the site,
  • to access all the features.

Before we chose to start with quality, we might discuss what the feature looked like, or we may already have a design for it. But then we’d just jump straight into the technical planning: how do we implement it, what code do we need, database schemas – that kind of thing. Instead, now we talk about the feature from a users’ point of view:

  • What happens if they get their password wrong?
  • How do they reset their password?
  • How long should the password be? Should it have characters?
  • What happens if a user doesn’t have an account, how should we direct them to sign up?
  • What kind of error messages do we want to show?
  • Etc.

This opened up a whole new discovery phase. Product Owners cannot think of everything when writing stories and this discovery allowed us to offer our insight into how the feature works, ask questions about how it should work and these are often based on technical knowledge of the platform that the Product Owner may not have. We began by adding these new requirements to the conditions of satisfaction, but they soon become long and arduous to check. So we looked for a better solution than acceptance criteria.

The solution we chose was to use a new tool. BDD (Behaviour Driven Development) is a method of functional testing which allows you to describe the functionality of a feature in a “scenario” file in plain english:

  • Given I am on the login page
    • When I enter ‘mikepearce’ into the username field
    • And I enter ‘butteryballs’ into the password field
    • And I click “login”
    • Then I should see my dashboard.

We can then use a BDD framework to run these scenarios against our web application. We use Behat as a framework and it works really well (apart from our problem of data fixtures…). It pretends it’s a browser (and, will use Firefox if it needs to work with javascript) and does what your user would do with your system. This allows us to have automated functional testing too. Awesome.

So, when we’re doing this extra discovery step, we record our findings as these step definitions, instead of acceptance criteria:

  • Given I am on the login page
    • When I enter ‘mikepearce’ into the username field
    • And I enter ‘wrongpassword’ into the password field
    • Then I should see the message ‘Sorry, your password is wrong’
    • And I should see the link ‘Did you forget your password?’

We slowly build up a specification file for this feature, which is mostly centred around the “happy path” and add edge cases or problem scenarios if we think of them. It’s important to note that we don’t expect to think of EVERYTHING in this session as we time box it to ten minutes and expect other features or ideas to emerge during the sprint.

Once we’ve finished, we’ve got a specification file that we can run against the web app with Behat. The first time we run it, it will fail, because the feature isn’t there – but this is good! This is Test Driven Development for the masses! As the team slowly builds the feature and keeps running the Behat tests against it, it will slowly become more and more green. If new things emerge during the sprint, we add extra steps to the scenario file. By the end of the sprint, all Behat tests will be green and we can have confidence that, not only is the feature defect-free, but it also does what the user expects it to and provides them value.

So, now we have a way of assuring that our software has quality. Not only do we have a slick set of automated functional tests, but we’ve also added a low-friction, low effort step of discovery that allows us to really understand AND define what quality means to us in the context of this feature for our product.

I’d encourage you to try this in your teams. Actually having Behat (or any other BDD framework) isn’t really a requirement to get started. You can start by just writing your scenario file as the first step of your team planning a story and storing it somewhere for future reference. The value is in the discussion you have to define the quality. The artefact you create is useful afterwards for checking that you meet those requirements. The added benefit is that it’s written in a language that anyone can read – from your team and product owner, to stakeholders and anyone else in the business who is interested to learn more about your product.

(The benefits of using BDD are outside the scope of this article for more than I’ve described, there are plenty of articles on the web to suit your style, language and infastructure and I would encourage you to learn more about it. Start with this presentation from Gojko Adzic and this from Dan North)

Have you read the manifesto?

I sometimes wonder whether people have actually even read the Agile manifesto. It is made of four core values and 12 principles, I won’t paste them all here, you can find them at the above link. Maybe the principles are hard to find, but you can read them here.

That’s all there is to it. Agile isn’t a “framework” or a “methodology”, if anything, it’s common sense. Common sense described in four values and 12 principles.

Agile is not a synonym for scrum, or kanban, or anything else. The term “Agile” shouldn’t be used as a description of an all encompassing set of practices that it doesn’t describe. For example, what does “Agile adoption” even mean in this context? Does it mean you’ve finally decided to use common sense? No, it means a company is adopting a framework or methodology that is inspired by the Agile manifestos values and principles, such as Scrum.

Agile is a mindset, a way of being. So please, stop posting things about how “Agile has failed”, or “Agile does damage” unless you actually mean that common sense has failed, or common sense has caused damage. Which is unlikely.

Remember, you don’t DO agile, you ARE agile, it’s a way of being, not something you do.

Estimating stories quickly and efficiently with ‘The Rules’

An Old Timer by hiro008
ticktickticktickBING - An Old Timer by hiro008 on Flickr

Estimating a backlog should be easy, especially if your Product Owner has looked after it, knows how to write good stories that mean something to the developers and the business and is able to prioritize based on business value (or, customer delight!). However, estimation meetings, poker planning, planning two or whatever you call it, can often be painful events that descend into chaos, anarchy and heated debate. While these things are all fun, estimation should be fast and simple, afterall applying arbitrary numbers, whose only measure is relatively sized, to amorphous items of work can’t be rocket science, so why would you want to spend much time on it?

Trouble is, developers and engineers are paid to solve problems, that’s what they love to do, so they begin the moment the problem is presented! This is to be applauded, but doesn’t really nail what should be fast conversations about stories!

We’ve recently been coarse estimating the next releases’ worth of stories for each if our products, the backlogs for these products contain between eight and 38 stories, depending on the goal. When we started estimating these, it was clear that it was going to be painful, so I created ‘The Rules’ (to be clear, they’re guidelines, remember the Shu Ha Ri!):

  1. Reset the countdown timer to five minutes.
  2. Product Owner reads story and acceptance criteria.
  3. Team ask questions to clarify their understanding of the feature. No technical discussion.
  4. When no more questions, the team estimates.
  5. If estimates converge or there is consensus, GOTO 1 and start a new story.
  6. If no consensus, start more discussion. Technical discussion is OK here.
  7. When the conversation dries up, or the time ends, whichever is first, the team estimates again.
  8. If estimates converge or there is consensus, GOTO 1 and start a new story.
  9. If a consensus isn’t reached, reset the time for another five minutes.
  10. When the conversation dries up, or the time ends, whichever is first, the team estimates again.
  11. If a consensus still hasn’t been reached after 10 minutes, put a question mark next to the story and GOTO 1 and start a new story.
  12. Optionally: create a spike story to discover more information in order to estimate the difficult story.
This means that the team will never take more than 10minutes to estimate a story. Usually, I’ve found, that the first estimate, right after the PO reads the story and the team clarify their understanding, is enough and rarely do we need the time for the second timebox of five minutes.
Remember, these are just estimates, they can be revised later if necessary and, really, the important part of this meeting is the conversation to clarify the requirements and, thus, ensure that business value is met.

The Definition of Ready

Well, I’ve only gone and got myself published on the Agile Journal! Here is what I had to say:—–

Ready 4
Are you ready? Image by Kevin Dooley on Flickr

Development teams use the idea of a definition of done (DoD) to decide when they think a user story is ready to be shown to the stakeholder for review. The DoD is like a bouncer or doorman, ticking technical criteria off on a list before the story is allowed in to party. The DoD is a powerful tool, and while its explicit value is obvious in ensuring the quality of a user story before review, its implicit value is equally, if not more, important. The DoD forms a contract between the development team and the product owner (PO). This contract not only ensures that stories meet a baseline of quality but it also creates a bond of trust. The PO knows that, with a DoD, he can trust the team to deliver a quality technical solution, and in agile software development, trust is key to your success. The acceptance criteria form a similar bond between the PO and the stakeholder or business. The criteria are designed to help a PO decide if a story meets the stakeholder’s requirements. It’s this list—defined in conjunction with the stakeholder—that creates trust on the stakeholder’s side. They know that their PO will deliver what they need, because it says so on the story. The DoD and the acceptance criteria combine to make a powerful ally for your team’s success. But both of these things require that the user story itself is sensibly written and defined and that the acceptance criteria aren’t some magical pie-in-the-sky, moon-on-a-stick list of ridiculous demands that would give a hostage negotiator nightmares! The PO can make use of a similar DoD called the definition of ready (DoR). This can be used for all the same reasons the DoD is used for the team. It’s useful if the Scrum team helps the PO come up with a DoR, help her define things about stories that make them easy to understand:

  • small enough to be manageable in a sprint
  • contain enough detail to estimate accurately and
  • create acceptance criteria that really help define “done.”

POs don’t just pluck an idea out of the air, write a user story, and drop it onto the backlog (we hope). Stories go through a process just like the software they drive does. The PO has a responsibility to the team to create user stories for them to estimate and, at some stage, work on, that aren’t badly defined or not thought through. Team members don’t want to have to do a bunch of the PO’s work in order for them do their own work and deliver value. To this end, a PO and the Scrum team might find the DoR useful. This is a contract that the PO has with the team in order to say “Before I put a story in front of you, I will have done everything I can do make it not suck.” Some examples of criteria on a DoR are:

  • Story contains actors, problem, and value
  • Story should fit in a sprint
  • Story should be appropriately documented (does it require wireframes? User-journeys?)
  • Value should be obvious, if not, it should be explicitly stated
  • Story should have reasonable conditions of satisfaction
  • Story should focus on problems, not solutions

Using the above example, we could ensure that the user story: Show users other products that they can buy before they checkout which begins life as a throwaway request from a stakeholder at an audio-visual online storecan be rewritten using the DoR as: As a customer, I would like to see products that I might like to buy at the same time as my television, hi-fi, or other product, so that I can be certain I have everything I need. Acceptance Criteria:

  • Show users products that other customers, purchasing the same products as this user has chosen, have bought also
  • Based on what the user has added to his basket, show him products that could potentially be used with it, e.g., if he has chosen a TV, then show him cables, TV stands, and Blu-Ray players
  • Show ratings and percentage of customers who ended up adding the additional products to their basket.

This shows the actor, problem, and value for the customer. The value for the business is implicit in that it will increase uplift. The story is appropriately documented with reasonable acceptance criteria, however it doesn’t tell the developers how it should be done technically. I’m a big fan of release planning meetings. These meetings include going over the team’s DoD to see if there are any changes team members want to make in conjunction with the PO or stakeholders before they start sprinting. This is an ideal time to create your DoR as well. In addition to the explicit value you get from having a contract between the Scrum team and the PO, the DoR also goes a long way to fostering trust (as long as the PO follows through) in the same way that the DoD and the acceptance criteria do. If you have a bad sprint, during the retrospective, you can review your DoD and your DoR. Did the story require more work before it went into the sprint backlog? The DoR provides a similar yardstick to that of the DoD when looking for root causes of failure. Try adding a DoR to your process, especially if you’re having trouble with your stories being difficult to estimate or work on. You’ll reap benefits immediately, building trust and creating stories that have real value.

Lower the pain threshold and you’re not waiting, you’re impeded.

Jenny by  jamesfischer on flickr
Jenny by jamesfischer on Flickr

Women, it is said, have a higher pain threshold than men. I saw evidence of this as I watched my wife give birth … twice. She went through something that I can’t even imagine having to endure. I’d have screamed ‘epidural!’ the moment the first contraction hit, but then I am known to be a bit of a wuss. My wife however, gritted her teeth and got on with it, I’ve never been more proud.

I’ve witnessed a similar thing with scrum teams. Some of the teams I coach have an extremely high pain threshold when it comes to dealing with impediments. It’s often been one or two days later that I’ve even heard about the impediment, let alone had a chance to deal with it. I suspect this might happen in other teams too and it’s worrisome; it may mean that the team doesn’t believe their SM will be able to remove the impediment (which would illustrate a trust issue and is the subject of another post), it might be a show of machismo to tough out the impediment themselves and resolve it without bothering anyone. This is an honourable motive, but chaps, this isn’t 12th century Japan, if you need help, you can, and should, ask for it. Understanding when you’re impeded and recognising the need to seek help is a more macho thing than flexing your muscles and baring your teeth, it also makes the ladies swoon*.

However, the most likely reason that people don’t raise the issue, is the team simply don’t see it as an impediment in the first place. In standups, or in just day-to-day team chat, the term “I’m waiting for…” crops up quite frequently, usually in reference to the design or operations team. This term is poisonous, it’s a pseudonym for “I’m impeded by…” and teams don’t recognise this is the case.

If you’re waiting for something to occur before you can do something else, you’re impeded by it and your best course of action, if you’re unable to un-impede it yourself, is to raise it to your SM (or your coach. ;)) and have them try and remove the block for you. Next time you catching yourself saying “I’m waiting for…” remember, you’re impeded.

Don’t tough it out, leave the high pain threshold stuff to the mothers of the world, they’re much better at it.

*Probably, I have no data for this, I made it up.

Should I start with scrum, or kanban?

or, Should I transition from scrum to kanban?

Tellurian Post Apocalypse Roleplay
Adventure lies EVERYWHERE! Image by Daniel Voyager

We’ve been doing scrum at Affiliate Window for a couple of years now. We go through the inspect and adapt cycle regularly and we’ve made few, if any, changes to our process, only our engineering practices. Recently, however, we’ve been working on a couple of projects which have required some groundwork and lots of backend work. This kind of work doesn’t really lend itself to the ideal of having something to show the stakeholders at the end of every iteration. We still have the review, describe what we’ve done and then take a look at the backlog with the stakeholders to decide what the priorities are for the next iteration.

This has raised a question from one of the teams about moving over to kanban and it got me thinking about what organisations can do to start on an agile journey, should they start with scrum, or kanban? What about established teams? Can they transition from scrum to kanban, or vice versa? Why should they? Should they even do it?

Now, there’s no reason why you can’t continue doing scrum (which is what we’ve decided to do), even with backend heavy work. Afterall, it’s simply a framework designed to offer constraints in order to create fast feedback (amongst other benefits), but kanban is attractive in that it allows you to decide when you demo/review and so gives you the benefit of time in order to actually have something tangible to show the stakeholders. Kanban is also attractive for those coming to agile afresh. It allows you to start integrating some agile practices and get a view of your issues (in order to solve them) without changing your heirarchy or existing process.

For Kanban to really work, you need to make sure you’re setting up a pull system that describes your entire process, from inception to delivery – not just a column based todo board (which, unfortunately, you see a lot described as ‘kanban’). To be able to do kanban well and retain the holistic view of your work required by the product team to make educated guesses on delivery and suchlike, the team needs to be mature enough to do kanban well. This means; mapping out the different states in your system, working out WIP limits and, importantly, deriving cycle time (how long it takes an item on the board to get from left to right) in order to estimate delivery/scope/cost etc. Herein lies the rub (I’ve always wanted to put that in a blogpost!).

If you’re not able to use scrum to help you deliver backend-heavy, large work items, then it’s unlikely that kanban can help either. The constraints of scrum help you stay on target and be accountable for what you have or haven’t done and make tweaks and adjustments to perform better in the coming iterations. Once you’ve nailed scrum and you have a product backlog with well defined stories, which are easily estimatable, then you’re ready to mature to a really valuable, efficient and data-driven kanban implementation. Eventually, when you’re able to size your stories all the same, you can do away with estimating as your cycle time will remain constant. Allowing you to set regular reviews and inspect/adapt cycles. You’re one step closer to programmer anarchy!

So, should you start with scrum, or kanban? Kanban allows you to start your agile journey without upsetting the status quo; you don’t change any names, or add/remove roles. You simply illustrate your process on a big visible board and become accountable, as a team and a company for the work you do. You can implement any agile practise you like (standups, backlogs, user stories, etc) and see how they work for you without rocking the boat. Scrum, on the other hand, requires a reboot and an installation of a new process, one with constraints *built in*, but the benefits are numerous and valuable right off the bat.

Should you start with scrum, or kanban? The answer, I think, is ‘it depends’. If your organisation, including those at the top are comfortable with scrapping your current process and starting something new, even with it’s inevitable lead time, then go for it. Use scrum and the constraints will help you become agile. If your organisation is reticent to start, or you have buy-in from teams, but not the business, then start with kanban. It’s lightweight and non-intrusive and will still allow you to raise your impediments and issues (but solving them often requires bold and honest action, beware!).

Should teams transation from scrum to kanban? Probably, but make sure it is for the right reasons and that your team is mature enough to make the most of it, if you’re not sure, then try transitioning via scrum-ban, it’ll help you see the benefits and enable you to get better at the things which make kaban most useful, without changing more than you are comfortable with.

I’d be interested to know how others started their agile journey, or whether many transition from scrum to kanban (or the other way). Drop me a mail, tweet or leave a note in the comments!

Failing sprints? Decompose your stories to the nth degree

Dive Off by Sebastian Mary
Is he about to fail his sprint? Image by Sebastian Mary

Recently I had a retrospective with one of my teams after two failed sprints. They cited unplanned tasks as one of their issues and suggested that perhaps the scrum framework wasn’t right for the kind of project they’re currently doing.

To give some context, this is a long running team on a long running project with no kind of release windows. One mistake that we did make was that there wasn’t a ‘Sprint Zero’; a chance to look at the project as a whole and do some time-boxed up front planning for a sprint. However, we’ve entered two sprints without some knowledge of how we plan to do things and it’s caused bad sprints.

When we began to plan the current sprint. There were some ‘technical’ stories in the backlog, for large chunks of backend work which had other stories dependent on them. They were all estimated quite high, without acceptance criteria or the ‘As a …, I need …, so that … .’ stanza to support them. This is fine, the stanza is only important when it provides value and usually not for technical stories. One of the problems was not having acceptance criteria, so the first thing we did was to define those.

After that and to get to the crux of the post though, I asked :

Describe this story in high-level steps.

To which the team discussed what would be done to do each story, we defined the tasks at a high level (much like you would do when planning proper), but after each task was defined, I asked the team to estimate the tasks in story points. It was an eye-opener!

The tasks were all coming in with estimates of 2’s and 3’s. Which meant that, when the broken down, estimated tasks were added up, they were more than the original story. This usually happens, but it was an ‘Ahha!’ moment for the team. It allowed them to think more abstractly about the work. It’s not the plans that are valuable, but the planning!

To compound the issue, we’ve been getting hung up on the idea of each story delivering functionality which we can demo. While this is a noble goal, I’m sure it’s not always possible. This was causing huge estimates on stories and, as we know, bigger estimates mean lower accuracy on that estimate. With this constraint removed, the team breathed a sigh of relief and began writing stories which were meaningful and well sized. What actually came out of it is that, once we’d broken them down, we could see that for some of them, there actually were things we could demo; speed improvements on database queries and data integrity which DO provide value and so can be demoed.

Finally, when choosing the stories to add to the sprint, the team committed to work which they used their gut feel (and their velocity, but only as a guide) on what they could fit in. I went through each story asking, ‘Can we do this and all the previous stories?’ They committed to less than they would have had they just added the original stories. Meaning that, the non-decomposed stories were causing them to overcommit without recognising it.

So, if you’re failing sprints due to unplanned work cropping up and causing you to have over-committed, then ask for high level tasks on how to complete the story and estimate each of these tasks as if it were a story, you can go too far by decomposing each task to a story level, but if you’re finding this is the case, then your failed sprints probably aren’t caused by your stories.

Speaking at the London Global Scrum Gathering!

I’ve held off mentioning this until I got back from holiday, but I received this email while away:

Your submission, ”The Anatomical Dissection of a Sprint Backlog”, has been accepted into the programme for the London Global ScrumGathering on the 11th-13th of October 2011.

I’m so excited about this, you have no idea! So, if anyone has any great charts, graphs, hints, tips or ideas on how to use your sprint backlog, then let me know!

Agile core values: Individuals and interactions over processes and tools

Actual is not normal (a tribute to Edward Tufte) by kevindooley
Actual is not Normal

The four core value of the agile manifesto are values which I strive to live by, both at home and in my personal life (where it fits, my wife doesn’t care how I write a birthday card, just that I do (although, I suppose that fits too!)). It’s the very core of my job as an agile coach, so I though it was a bit time I wrote a few articles exploring them and what they mean.

I really should have posted this sooner, but, for some reason I haven’t. I think, mostly, because I realised that I needed to get a better understanding of what the values (and principles, but they’ll come later) really mean. While I recognise that being agile is not a destination, but a journey (cheesey, right? But true). I think my understanding of them is now deep enough to write about them, so, without further ado, I present the first in a set of four articles…

Individuals and interactions over processes and tools

I struggle to believe that, in any organisation, there are people that think there is anything that is more valuable than it’s people. If you’re in one of those organisations, then, it’s probably time to look for a new job.

People are the one most important asset in any organisation and the key word here is ‘individuals’, no one wants clones working for them and the more diverse the people you work with are, the more satisfying and fruitful your work life should be. Having an interesting and diverse set of colleagues makes it that much easier to get up and go to work in the morning!

One of the mistakes that I often see made (and, unfortunately, perpetrated by a lot of online and digital scrum tools) is forcing yourself into using a process. It’s interesting to note that the two most popular agile methodologies don’t prescribe any particular process to follow with software development, but people believe that they do. Kanban, for example, is not just a board with a ‘todo’, ‘in progress’ and ‘done’ columns. Each column marks a step in your process. The process you already have. Scrum also doesn’t tell you how to build your sprint backlog, instead, it just says you should have one and is quiet on what you should put on it (with the exception of the sprint burndown, but that isn’t a process, just a tool).

Most companies will already have a process for the way they write software before they begin their journey toward being agile. Sometimes it might be as simple as describe, develop, deploy. Other times it will involve review, QA, regression, analysis etc etc. When you start your agile journey stick with the process you have, don’t make things harder for yourself by changing too much. Introduce the framework of choice and use it to help you see where your problems lie. Then, slowly, organically and by small, incremental changes begin to adapt the process you have into one that allows you to align with the agile principles and create great software (or any other product for that matter).

The point of this is that, really, the process doesn’t matter so much as the people using and creating the process. The tools they use don’t matter as much as the indiviuals working together to create the process and create, or use tools which support their endeavours. Having a process is important, but not as important as the people in your organisation using your process and adapting it to suit their needs in order to attain the principles of being agile. Having tools is important, if they’re the right tools, but not as important as how you use them and what you use them for.

If you’re somebody looking to implement agile in your organisation, or someone trying to make your organisation adhere closer to the agile ideals, then empower your people to improve themselves and their process and then leave them to it.

Hire good people, then get out of their way.

So, that’s the first core value. Next time, working software over comprehensive documentation.