When I talk about estimation and planning, people often ask me the above question. The styles of estimating I talk about are more frequently used in a non-agency environment, that is, somewhere maintaining a single, existing product, or creating one, for your own company from scratch instead of the agency method which delivers software per project, per client.
The problem with this kind of work is that of estimates. Typically, as an agency, you’ll be bidding or pitching to a client to get the work. The client will probably be soliciting bids from multiple agencies, so you need to either stand out from the crowd in some way, or be the cheapest (or, preferably, both).
The client will generally be looking for a fixed price too, this is so they can go back to whoever is commissioning the work and get funding, or raise a PO or whatever.
Sometimes you’ll be given a brief, which you might then turn into a functional and/or technical spec, which then goes to the client along with the quote, then there’s some to-ing and fro-ing, an agreement and then work commences and oh shit, we forgot to add the widget to the spec and oh crap we underestimated the amount of data we’d need to use and have to re-engineer to use mongodb.
So, with this in mind, how do you estimate, quote, pitch or bid when agile methods are so fluid and you have to work to a fixed cost? You know the least about how long a project will take and what is involved right at the beginning. Using the Cone of Uncertainty, you’ll be between 4x and 0.5x inaccurate with your estimate of an end date (eg: at the beginning of a project that you estimate takes a month, it could take between four months and two weeks)?
There’s a few metrics you’ll need in order to derive costs from estimates:
If you don’t have this data, you have two options: guesstimate, or use the cone of uncertainty.
The fundamental tenet in any of these below strategies is complete honesty and transparency with your client. You’ll also need to invest three or four days (maybe less, it will depend on how practiced you are at this process, it will become quicker) in your client, it might sound like a lot and there is a risk there might not be a contract at the end of it, but it is worth it. Once you’ve deeply involved your client in the process from the start, they’ll feel like they’ve already started the project and so it’s easy for them to transition to being a paying customer.
From the outset, you’ll need to explain that you do things a little differently to other agencies. Whatever framework you choose to use (scrum, kanban, etc), spend some time explaining to the client what it is, how it works and why you use it. If you’re a little stuck, here are some ideas
The best way to do this is to invite your client in for a half-day, high level training and workshop. Run some exercises to illustrate the key points and answer all their queries – this is a new thing for many companies who aren’t used to this kind of agile environment, so it’s definitely worth introducing your client to it if they haven’t experienced it before.
The next step is to create some artifacts. Once you have a brief in hand and have spent some time with your product team and analysts and have a really good understanding of the brief, the market, the competitors etc, invite the client in again in order to build a product backlog of user stories. Set the scene for them and explain that, unlike other agencies, you won’t write a functional spec, or a technical spec, because they’re a waste of time. What you will do is write user stories, which describe each feature from the users’ point of view and what value each of the stories will bring.
Labour the point too. Ensure your client *really* understands that you won’t be building ANYTHING that you can’t find the value for and WHY you take that stance. If a feature, or some functionality, has no value, then why would you build it?
Work quickly through the brief and your research and build a backlog of epics with your client. Don’t spend longer than an hour or two on this and, if you have somebody, get someone to facilitate the meeting so you don’t get bogged down in ANY technicalities, or discussions that are long or drawn out. Once you’ve got your list of epics, have the client order them – which are the highest priority things? What user/customer value do they want to deliver first? Don’t worry about dependencies right now, this is only rough.
Finally, break the highest priority epic into a few slightly smaller stories. This isn’t strictly necessary, but will help the client understand the process better. Again, this shouldn’t take longer than 30 mins.
Now you’ve got your feature list of epics and some smaller stories for the highest priority, get some estimating done. I won’t cover it here, but you can read the article on white elephant estimating, or watch my presentation on agile estimation. Try and use the team that will actually be doing the work. If you haven’t got a team, or not sure which of your teams will be doing it, then pick engineers, designers and QAs from multiple teams – you’re only looking for roughly accurate figures. If it’s proving too difficult because of the epics, then break some into smaller stories – getting epics and stories sized well enough to estimate will become easier with practice.
Finally, you’re in a position to pitch, but how do you do it? It all depends on your clients requirements.
It’s very important that the client understands they have complete control over what goes into their product on a sprint-by-sprint basis. Explain that you expect them to be involved in the decision making about what goes into the product, the priority of the features to be added and the scope. So, once you’ve agreed on one of the below strategies and signed a contract, the success of the project will be partially down to their input.
If your client requires the project to be finished by a certain time, you can work towards that. It will be to your advantage to provide two estimates though, allowing the client to choose their own end goal:
All stories by the deadline
Estimate the number of teams or people required to deliver all the story points by teh date, then, based on a day rate, create a figure. Remember, to be accurate (but not specific), you’ll need to provide a range, so, using your best, worst and average velocity you can say to your client, “We ESTIMATE, it will take four months, but it could take up to five and half, but it could take three months, therefore, it will cost between £40,000 and £55,000″.
A valuable, shippable product by the deadline.
Do the same as above, but use a fixed sized team – you won’t be able to fit some stories in, but this is fine. Use the average, best, worst to show the client the stories you will definitely do, you will probably do, you might do and you won’t be able to do. This will reduce the scope of the project, but also the cost. Remind the client that what features make it into the product is based on their input.
Working towards a fixed cost is quite rare, but does happen and it will likely mean that the client won’t be able to have all the features they’ve asked for. In order to work towards a fixed cost, you need to know it (obviously…). Once your client has offered this, you can use it to work out your strategy. It will be similar to working out a fixed deadline. You know how long you have to deliver the project based on the day rate (fixed cost / day rate = number of days). So, then you have a fixed deadline to work to and can use the average, worst, best strategy again to indicate what you can definitely achieve, what you can probably achieve and what you definitely won’t achieve.
Finally, there is fixed scope. The client has to have everything they’ve asked for – in practice, during the project, this is rarely true once you start building and the early, regular releases helps steer the project.
Again, using your best, worst and average velocity, you can work out a range of how long it will take and then use your day rate to provide a figure.
(I wouldn’t suggest this method unless your client is particularly agreeable to trying new things, but, assuming you did the setup correctly I describe above, then they should be chomping at the bit to try this new, visible, transparent and honest method of commissioning software)
Pitch at a cost per iteration, instead of a day rate. You can give rough estimates on how much it will cost and these will become clearer after each iteration. Pitch for a minimum number of iterations after which your velocity will stabilize and you can be more accurate in the remaining length of the project. This is a fairly ambiguous method of pitching though, you’ll need to draw on the other strategies above to work out what features and functionality can be delivered, but if your client agrees to sign you for a minimum number of iterations, and you deliver what you agreed to, by this time, your estimates should be pretty accurate and your velocity very stable, allowing you to accurately cost any stories you haven’t managed to complete.
It’s worth reiterating here that you should be completely honest with your clients as to how complicated and amorphous quoting for a software project is. If you think your client can understand it, then break out the cone of uncertainty to explain that 40 years worth of data prove it to be true.
Explain that, being agile and adopting a framework to allow for short, deliverable cycles allowing for fast-feedback means that your company will very quickly start delivering visible value to them. It will also mean that they can control what that value is on an iteration-by-iteration basis. But, probably the best arrow in your quiver is to explain that, throughout the project, they can see the progress on an almost daily basis and adjust both what you deliver and how much they want to pay you should they need to.
If you deliver some valuable piece of software that causes them to change they way they think about their product, then they could pivot their entire offering and find more funding – and who is already in place to help them achieve that?
Congratulations! Now, don’t sit on your laurels. Remember the commitments you made to your clients during the pitch process and keep them involved through the project. Begin with release planning to decompose the epics into more usable stories and begin to uncover more of the project as you go, with milestones and deadlines if necessary. Keep your client informed, involved and in-the-loop and they’ll be happy when things change (and they will).
Sorry, that sucks – but use it to learn a lesson. Find out why you didn’t win. If it’s just down to cost, then perhaps review your costs, or spend more time breaking down and estimating the stories to provide a more accurate figure next time.
Send out a survey to the client, asking them what they thought of the process and whether there is anything they’d change, or something they didn’t like. Gather as much data as possible, then spend some time retrospecting with your teams about how you can do it better next time.
My advice here would be to not take on the business. If your client isn’t interested in being part of the process of building their product, then you are setting yourself up to fail. You’ll deliver a functional and technical spec detailing exactly what they want, you’ll deliver it and then find out that, while you delivered what they asked for, it isn’t what they wanted.
The old black box model of estimating and pitching for client work is difficult to manage, hard to sell and will bite you in the ass later down the line if you got it wrong at the start. By getting your client on board and understanding how you do things, and that they can and should be involved from the beginning to the end, you put yourself, your company, your team and, importantly, your client in a position to succeed.
I help my first retrospective for a while recently (that’s not to say the team hasn’t been retrospecting, just that others have been doing it in my stead!) and the team wanted to do the Mad, Glad, Sad exercise.
Shockingly, I didn’t know it. Or at least, I didn’t think I did.
The exercise starts with everyone writing on three different coloured posts-its the things that made the mad, glad or sad during the sprint. We then stuck them all up on the whiteboard under an appropriate picture.
We all studied it for a while, but I couldn’t really work out what the difference was between mad and sad. The idea of a retrospective is that you inspect and adapt. Look at what you did, how you did it and change things if they need improving. The idea of mad and sad should be things that, affected us negatively that we want to change in future sprints.
But what is the difference? I asked the team. They didn’t know either.
So, we set about trying to decide what each thing meant. In many retrospectives in the past, we’ve realised that there are things that went wrong, didn’t work or just plain sucked that we could fix and there were things that can be classed as ‘Shit Happens’. Stuff that, while we might expend some effort in fixing them, are unlikely to occur anytime in the near future, so we draw a line under it and move on – there are always more pressing things to deal with.
So, using this idea, we renamed Sad to “Get stuff off my chest” and Mad to “I’m not going to take it ANYMORE”.
This means, we can highlight things that annoyed, frustrated or saddened us, but that, realistically speaking, there isn’t a lot of value in dealing with and then the stuff that REALLY got under our skin and we have to deal with.
Once we’d renamed them, we then re-sorted the post-its we’d stuck under the two columns and found that, things we might have dealt with as a real problem and spent time working on, were no more than just people wanting to have a rant, and real problems might have been overlooked as they hadn’t been applied with enough gravity. Perhaps the team member feels that it’s just something bothering them and doesn’t want to make an issue of it.
We worked through all three columns and, during discussion, decided to move some from Sad to Mad and vice versa as we discussed the pros and cons of each. In the end, we had a good, solid list of things that ‘we’re not going to take ANYMORE’ which turned into a list of definite actions.
So, if you run this exercise with your team, check their and your assumptions about what Glad and Sad mean – you may be met with blank looks – and make sure you all have the same understanding to make a good exercise into a great one.
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.
I gave a talk at LondonWeb a couple of weeks ago. It was a lot of fun. I tried to broadcast it with Google Hangout on Air, but the hotel wi-fi was rubbish. Luckily, @nathanlon recorded it too, so here it is:
and the slides:
Slides for ‘How big is it? A guide to agile estimation’
So, George Osborne today announced that, in exchange for between £2,000 and £50,000 of shares, employees can relinquish some of the rights they have as employees. These rights are; claiming unfair dismissal, redundancy, time-off for training and flexible working. There’s also an extra right to relinquish for women, which is to give 16 weeks, instead of 8, notice when returning from maternity leave.
Essentially, what Mr Osborne is saying is that you can either be a) ejected from the company with no recourse or b) imprisoned at your company with no way out for some figure between £2,000 and £50,000.
I understand that this comes down to a matter of ‘shared-ownership’, meaning that, now you have these shares, it’s up to you to do the very best you can to make the company a success, afterall, if the company is a success, you’ll do well too. I also understand that this is voluntary for existing employees, but could become compulsory for new employees, should an employer choose to do it that way.
What I don’t understand is how on earth he thinks this is a good idea? Claiming unfair dismissal is what protects employees from the pointy-haired bosses who surround them. Redundancy, unless political or strategic, would indicate a company not doing so well (so, who would want shares?). Training is important if you want to retain, improve and increase the value of your staff and flexible working? What on earth does he mean?
For some shares, you get to give up the ability to work from 9 – 5:30, every day in the same office? What a marvellous idea! Let’s ignore the fact that people don’t all march to the same drum – folks aren’t productive when you want them to be, they’re not creative when the clock showing a specific time. Let’s ignore the fact that people have children, families, teeth, health and the multitude of other things that mean working 9 – 5.30 is difficult and a dumb idea. Further, we should force people into thinking that spending time in a particular location, between particular hours is a measure of how well they’re working. Let’s completely ignore the fact that by focussing on WHEN we are, we cannot focus on WHAT we do. Business should focus on results, not hours.
This new proposal from the CHANCELLOR OF THE EXCHEQUER clearly shows that he has almost no idea how business works in the 21st century. Stop trying to apply old fashioned, often Taylorist views, on how you think businesses should be run and be forward-thinking, pragmatic and revolutionary in helping small- and medium-sized businesses achieve greatness.
I read a lot of blog posts, articles, papers and what-not on creating, maintaining and coaching teams. It’s the one thing that, for me, has no set formula. Each team is different, as they’re made from different individuals, each with their own set of morals, ethics and experiences that drive their behaviours. There is no ‘one-size-fits-all’ team guide, unfortunately.
So, what we’re left with is a miasma of different works, all decrying or promoting some way or other of how to form and maintain a team, how to help them become high-performing, how to retrospect, plan, work, play, love, eat, argue and play football together. None of them are right and, equally, none of them are really wrong. But the one thing I see frequently is suggestions, and often demands, that “if they don’t fit, you’re hiring wrong/replace them” and this is alarming.
The common theme I see is that, yes, there IS a formula for creating the winningest team and, if one of the members of the team you’re trying to engineer to stardom doesn’t fit your mould, then he’s out on his ear … hit the road jack, your awesome-coding-but-complete-lack-of-personal-skills ass is outta here!
Not everyone can be a rockstar, you need some roadies too.
Perhaps you know someone, or have someone in your team who doesn’t really have any great ideas, isn’t that keen on researching the latest javascript framework or building some wanky Hipstagram filter in Ruby, but who can build a data abstraction layer, fully unit tested in a day and always reviews your code and finds the one or two things you missed. Where would you be without this guy?
Or maybe there’s the guy who just REALLY enjoys honking about with MySQL queries, doesn’t really give a rats ass about what the business does, but cares deeply about the quality of his code and making his queries elegant and fast.
Some of you may know the guy who get’s a real kick out of cutting HTML all day, taking the photoshop files from your rockstar, sweater-vest wearing, macciato drinking, fixie-bike riding designer and making a cross browser compliant, responsive and even working in IE.
These guys may not be the fastest, or the bloggiest, or the githubbiest, they may not even really get on that well with agile estimation, sprinting or ‘stakeholders’, but they’re rock solid and dependable.
Everyone has a place, even if they’re wearing a christmas sweater in June, they’re part of your team. Find a place for them, or, better yet, let them find their own place and do what they do best, even if it doesn’t align with your idea, or the internets’ idea, of what a perfect team is.
They tune the guitars and your rockstars play ‘em. That’s what a real team is.
Some of us inherit teams. We don’t have the luxury of hand picking the people we want to have. Maybe there just isn’t enough in the budget to fill your team with rockstars. Software gets written outside of Silicon Valley too!
This, for me, is the real notion of building a team. Not chucking money at a bunch of rockstars, but taking what you have, or building on a small budget and creating a live band – you need rockstars AND roadies if you want to wow your audience.
So, I’ve been messing about with Behat recently to try some tests of our site. I was given the challenge of testing the ‘Refine By’ functionality of our directory search. I thought it would be easy (it turned out to be, but not until I’d wrapped my head around XPath). Anyway, the refine by options are just bits of text in a label, or even a span in a label:
<ul> <li><label><span>Refine Heading</span></label> <ul> <li><label>Refine criteria</label></li> </ul> </li> </ul>
Not great HTML you’ll probably agree, but clicking on the ‘Refine Heading’ or ‘Refine Criteria’ shows and selects criteria with javascript. However, there isn’t an out-of-the-box assertion for this with Behat, so after some fumbling around, I made (most of (some help from General Grecki)) this:
/**
* Click some text
*
* @When /^I click on the text "([^"]*)"$/
*/
public function iClickOnTheText($text)
{
$session = $this->getSession();
$element = $session->getPage()->find(
'xpath',
$session->getSelectorsHandler()->selectorToXpath('xpath', '*//*[text()="'. $text .'"]')
);
if (null === $element) {
throw new \InvalidArgumentException(sprintf('Cannot find text: "%s"', $text));
}
$element->click();
}
I receive about 2 emails a day and probably three or four calls a week from recruiters who have an old version of my CV in their hand. The version they have is usually very out of date (some context: the company I currently work for employed me as a senior developer, then I became an agile coach, now I’m head of development) and is from a previous development job I had.
My question is, should I update my CV and upload to Monster/Jobserve etc and respond to recruiters with it so at least they send me emails and call me about relevant jobs, or is that sending the wrong message to my company?
To be clear, I’m not looking for a new job, I’m looking to reduce the amount of irrelevant mail and phone calls I receive.
How often do you update your CV or your LinkedIN profile? Does updating either of these things send the wrong message? Even if it’s just for the sake of updating it?
A had a text from a friend tonight, “They’re talking about you on the BBC!”, I was momentarily excited until I got the link to the audio from the Radio4 Today programme this morning, talking about working from home, it’s here http://news.bbc.co.uk/.
Apparently, 250 members of staff from a firm in China who worked from home were 12% more productive than the other 250 who worked from the office. The programme cites they study called Does Working From Home Work? A Chinese Experiment (Bloom et al, 2012). While the today programmed states a 12% increase, the study says there was a 13% increase; 9.5% for more minutes per shift and 3.5% as an increase in the volume of calls made due to a quieter working environment. However, one the nine month trial was over, the company rolled out WFH to the entire company, not everyone took the opportunity, some chose to come to work, about half those who were in the randomly selected working from home group and two thirds of the control group, those who worked from the office, chose to stay in the office. Interestingly, productivity went up more and Bloom et al state that, working from home as a modern working practise, along with the employee having a choice in how they work (which harks of Dan Pinks Autonomy, Mastery and Purpose piece), as a combination are very beneficial to overall productivity.
The experiment wasn’t ROWE though, the was a heavy focus on the amount of hours worked. In order to get some good measurements, they required those WFH to work specific times (9-5) as well as those in the office. As it was a call centre, measuring was fairly straight forward; they measure number of calls, notifications sent, corrections etc. The team leaders still dictated when the employee had to be in work as the experiment was only for four out of five days, with the team leader deciding on the day the worker had to come into the office. So, pretty far removed from ROWE, but still some good data on what it means to work from home.
ROWE in this context would be fairly simple to implement given the straightforward way they gathered and reported on the metrics.
However, the bottom line is – working from home is more productive … for the right kind of people (low performers generally chose to work in the office), but how much the culture of the Chinese and their existing working practises affected this outcome is pause for thought too. Working from home requires discipline, so this is where a focus on the results and how they can be measured is the most important thing about ROWE. If you know what you need to do and you’re going to be measured, it’s much easier for you to do the thing, knowing that that’s all that counts.
A colleague sent me a link to an article on the MIT website, ‘Why Showing Your Face at Work Matters’ and, frankly, it has really got up my nose!
The basic premise of the article is that, if you want to do well at work or in your career, then you need to put in some passive face-time (their emphasis!). Passive face-time is describe as just being in the office, not necessarily in a meeting. They go further and quote remote workers who do some, frankly, ridiculous stuff in order to be noted as having virtual face-time (my emphasis), that is, sending emails in the middle of the night, replying instantly to emails so it doesn’t look like you’re sunbathing at home, making regular email or phone updates, being ‘extra visible’ in the office and, my favourite, getting others to talk you up by being in peoples faces and forcing people to remember you (probably as the annoying one who can’t keep their nose out … whatever).
This is ridiculous! Why are these people wasting time on doing things that aren’t getting them closer to their goals or the company objectives? Surely, this is the opposite of what they should be doing, which is working on valuable stuff, ensure their boss understands what they’re doing and how they’re going to measure it and get evaluated on that?
The article also goes further and states that research suggests that those in supervisory or line-management roles will evaluate people differently based on this idea of passive face-time, they won’t, however, realise they are doing it (K. D. Elsbach, D. M. Cable and J. W. Sherman, “How Passive ‘Face Time’ Affects Perceptions of Employees: Evidence of Spontaneous Trait Inference,” Human Relations 63, no. 6 (June 2010): 735-760.). This reminds of that ridiculous “truism” – “Perception is reality” and something that needs to be rooted out, dragged into the street and shot.
MIT have studied this for a decade and settled upon two types of passive face-time; expected and extracurricular and, whichever version you engage in, changes how people evaluate you. Those who put the expected business hours in are called ‘responsible’ and ‘dependable’ and those who put in the extra face-time are ‘committed’ and ‘dedicated’. They conducted a few experiments on this (they were a bit flaky: getting people to read descriptions of workers, then evaluating them – these being workers they had never met or interacted with) and managed to turn their hypothesis into a theory, which is useful, but I’d like to see it backed up with WHY do supervisors do this and help them eliminate this harmful practise.
They sum up by saying:
“The bottom line is that employees should be wary of work arrangements that reduce their office face time, and supervisors should be wary of using trait-based performance measures, especially when evaluating remote workers.”
Which is what annoys me the most. It shouldn’t be for the employee to ‘be wary’ of having a more flexible way of working, it should be for the employee to enlighten their boss and say ‘Hey, measure me on WHAT I DO, not how often I am in the office/making a nuisance/sending emails.”. The onus is entirely on the bosses of the world to be proactive, take a holistic view of their department or team and think “How do we contribute to the success of this company?”, then build goals, objectives and visions around the answer to that question, then measure your employees on that. Then, supervisors wouldn’t need to be ‘wary’ of making trait-based evaluations, because they’ll have something tangible to measure.
Stop measuring perception and start measuring reality, it’s really the only metric worth pursuing.
I'm a hands on leader, known for my deep knowledge and experience of agile, its principles and methodologies, as well as my focus on results only and the culture that brings. I have established and maintained various agile teams as well as many XP practices in more than one fast paced environment.
I'm passionate about agile, leadership and culture and strive to deepen my understanding of these through practise, research and collaboration almost constantly. My experience has given me a broad knowledge of open-source tools and software, which enables me to make decisions that satisfy both technical and business needs as well as being able to translate these into business objectives.
My public speaking helps me engage with the community and forces me out of my comfort zone to seek new challenges and better understand my field of expertise.
Specialties: Coaching, Facilitation, Agile, Scrum, XP, Kanban, Lean, Web Development. Software Engineering. Software Architecture, ROWE, Management 3.0
As the head of a department comprised of four teams totaling 25 developers, designers and testers, I’m always honing my role as a leader. I’m completely results/goal focussed and have successfully introduced a Results Only Work Environment using Objectives and Key Results Planning as a measure. I lead from the front, so get my hands dirty whenever I can, recently introducing Behaviour Driven Development to the department to increase both the quality of our software and engagement with our stakeholders.
Reporting to the senior management, I am actively involved in all levels of decision making, from architecture and platform, to vision and purpose, however I take a pragmatic view of leadership and understand that hiring good people and getting out of their way is key to getting the results I need.
★ Successfully introduced a Results Only culture.
★ Introduced three month OKRPs to the department.
★ Formed an architecture team to oversee the platform.
★ Lead the formation of a UX team and user testing practices.
★ Liaise with parent company in Berlin to align co-development teams.
★ Recruitment, budgeting/forecasting
★ Department and company training on agile, scrum and lean
★ Ran two successful Fedex Days
With the company rapidly growing and recruiting a lot of new development teams to work on the flagship web application, Darwin, I was given the role of Agile Coach in order to help the teams craft and continually approve their processes and methods for delivering valuable, high quality software. I train the teams and the wider company, facilitate communication and ensure that Affiliate Window is known as one of the premier development companies in the world (which it is!).
The role of an Agile Coach is varied and difficult to define. It works on three levels:
As a coach, I help the teams to deliver high quality software, by teaching the ideas behind agile, the rules of Scrum/XP/Kanban/etc and helping to guide their continual improvement by empowering the team members to change their process and inspect and adapt. Also by researching new techniques, tools and methods to overcome any challenges we face as a team. Helping the teams to integrate Extreme Programming techniques into their development cycle and ensuring constant feedback, not only from their customers but also from each other.
As a coach, I help my company transition to an agile methodology, by teaching the four core values and 12 principles of agile, helping to apply these to the work my peers undertake and helping to understand why we're becoming agile and it's benefits. Empowering my colleagues to view their process and make changes to their workflow in order to increase quality and value at every facet of their working lives. Helping the product teams with their roadmaps so as to have a clearer vision and strategy.
As a coach, I help the agile community by putting into practice what I preach and feeding this information back to other members in order that we may learn as a collective, increase our knowledge of agile and be awesome.
Working as part of a sprint team tasked with delivering frequent, valuable updates to the flagship web application, Darwin, which connects affiliate marketers, with the merchants who want to use them.
With moving goal posts and very light requirements, the team practiced agile development with a just-in-time responsibility, coupled with a very modular, serviced based architecture, meant we could be very flexible with what we delivered and when. We rebuilt a prototype call tracking solution designed to be spread across multiple data centres by using stateless front end servers, using DNS round robin load balancing to reverse proxied loadbalancers. I also filled the two roles of both scrum master and proxy product owner, which wasn't easy!
Jellyfish is the leading Paid Search Marketing agency in the UK, using unique bid management methods on a proprietary online application. Working at Jellyfish has given me the opportunity to manage a large team of developers.
Not only do I fill the position of technical lead, I am also responsible for some elements of recruitment, coaching developers, presenting and pitching ideas to the business, demonstrating prototypes and meeting with clients as a technical consultant. I am also a confident speaker and often deliver technical or process oriented presentations regularly.
Jellyfish use the Agile methodology and more specifically, the Scrum framework.
I'm a Certified Scrum Master and this involves facilitating and arbitrating between the business and the development team in order to deliver. I have also been involved with managing a product backlog and I frequently write and edit user stories with and on behalf of the business.
I've been heavily involved in re-designing the development environment, introducing separate development, test and UAT servers as well as live.
I introduced and setup SVN source code control and I conduct regular team code review. I introduced peer reviews and perform risk assessment on various new proposals when required and am able to provide detailed technical explanations of our work to the Technical Director and Development Manager, as well as being able to provide less technical descriptions and diagrams to the Account Management teams to ensure they understand what we're doing and any impact it may have on them.
Jellyfish's client list boasts some big names, including Skype, the BBC and Dennis Publishing.
Freelance web designer/developer and photographer. Have undertaken contracts for many different clients, including hotels in spain, greetings cards manufacturers and market research companies in the City. All projects including web design, system architecture, development and photography.
My role at Jellyfish is leading a small development team in the creation of internal applications that allow the account managers to better analyse and manage their campaigns on a day to day basis. I am also a member of the team which runs the servers and databases on a day to day basis. Since I started, I have been closely involved with rebuiling the web side of the hardware architecture, development platform and the staging and live environments.
I was brought onto the team at TMGC to lead a small development department. They had limited resources and hadn't really begun to set up their infrastructure.
They ran online skill gaming sites (ie: making bets to win at games such as pacman, asteroids or pool). While there I built and commissioned an internal development server, a code repository which was then used to version code, image and media assets and all company documents.
I also made some fundamental changes to the way they developed, introducing project planning and the concept of PHP frameworks for Rapid Application Development. I also mentored younger team members hungry for progression.
I spent some time screening and recruiting new developers as well as coaching and training. I presented business cases for anything I thought necessary for the company to introduce technically and was involved with on- and off-site client meetings as a technical liaison.
MonitorMedia has an exciting client list including CocaCola UK, Pizza Hut, British Airports Association and National Insurance Group. While at MonitorMedia I designed and built W3C AAA compliant XHTML strict websites using OO PHP5 and MySQL. Projects were planned using Technical Specs, Functional Specs, UML and Use Case diagrams. I introduced a basic level of coding standards, as well as introducing the team to PHP and Javascript Frameworks.
Worked on the corporate website as a web developer/designer.