I know we had a thread a couple of months back about BA's - thought i'd start a thread for all those BA's/PO's/Developers/Scrum Masters out there (and i know there are a few) who have been sucked into the Agile world.
I am relatively new to Agile -maybe a years experience now primarily as developer/scrum master
As a rugby fan this is how far I got and then you lost me. Better luck next time.
@SDAddick I'm pleased that you've found something that you enjoy and seem genuinely to have managed to get it to work in even the most demanding sectors.
I'm a wee bit older than you (unless the millennium started in 1966!!), but like to think that I have adapted to change over the years and I do pick up new things very quickly (unless spotted by a copper)!
I have always worked for Barclays and for the last 15 years looking after some of the biggest law firms in the world.
Now to the Agile part...we have teams and teams of these people throughout my building, working on projects all over the place. Most of what they do has a profound effect on people they wouldn't recognise if one of them walked up to them and smacked them on the arse with a banjo. They develop systems and pat themselves on the back, having consulted with each other on what someone else, they have never met, would want. A case in point is the payment system we currently use. Agile means we can update this with new widgets far quicker than we ever did before. Unfortunately, every time we do a weekend "refresh", it's a bit like engineering works on the railways...you know damn well that you're going to be fucked on the Monday morning.
They're getting there in our place now. They are actually talking to us and I have managed to get the head guy out to meet several of my clients who were under orders to use the same language they had previously used with me. They seem to be listening, but it shouldn't have taken this long for them to do that. Their argument is that our Senior Management (yep, we're working for different senior management) signed it off. Unfortunately, I'd like to use that banjo on our SMT too, as they haven't a freakin clue what the client actually wants either (there seems to be a link here for SMTs).
As it goes Agile, or any new system, is only ever going to be as good as the people who are running/implementing it. As good as the information that goes into building it and understanding that every action has a reaction and what you need to do to ensure that that's a reaction that you actually want.
Don't want to piss on anyone's parade, but a lot of us who have looked after people for a long time call that business as usual...its just about making sure that the right people get it and act on it.
@SDAddick I'm pleased that you've found something that you enjoy and seem genuinely to have managed to get it to work in even the most demanding sectors.
I'm a wee bit older than you (unless the millennium started in 1966!!), but like to think that I have adapted to change over the years and I do pick up new things very quickly (unless spotted by a copper)!
I have always worked for Barclays and for the last 15 years looking after some of the biggest law firms in the world.
Now to the Agile part...we have teams and teams of these people throughout my building, working on projects all over the place. Most of what they do has a profound effect on people they wouldn't recognise if one of them walked up to them and smacked them on the arse with a banjo. They develop systems and pat themselves on the back, having consulted with each other on what someone else, they have never met, would want. A case in point is the payment system we currently use. Agile means we can update this with new widgets far quicker than we ever did before. Unfortunately, every time we do a weekend "refresh", it's a bit like engineering works on the railways...you know damn well that you're going to be fucked on the Monday morning.
They're getting there in our place now. They are actually talking to us and I have managed to get the head guy out to meet several of my clients who were under orders to use the same language they had previously used with me. They seem to be listening, but it shouldn't have taken this long for them to do that. Their argument is that our Senior Management (yep, we're working for different senior management) signed it off. Unfortunately, I'd like to use that banjo on our SMT too, as they haven't a freakin clue what the client actually wants either (there seems to be a link here for SMTs).
As it goes Agile, or any new system, is only ever going to be as good as the people who are running/implementing it. As good as the information that goes into building it and understanding that every action has a reaction and what you need to do to ensure that that's a reaction that you actually want.
Don't want to piss on anyone's parade, but a lot of us who have looked after people for a long time call that business as usual...its just about making sure that the right people get it and act on it.
McTel, yes, very fair, espcially that part. If you have good people, good things happen, and vice versa. Agile, as I think of it, is a great way to get more out of good people with empowerment and buy in. But if people are insular and isolated, Agile will not, on its own, change that. But what Agile can do (and here's where the Marxist in me comes out) is create a pseudo-democratic workplace in which employees have more of a say on what the company does, and that can lead to better productivity and creativity.
One thing I come across a fair amount is how well Agile scales, particularly to large organizations. And the answer is...from what I can tell not that great most of the time. There are a lot of reasons for that, and I think a big part of it is what sounds like is happening with you--large companies are compartmentalized so collaboration and cooperation with each other, let alone the outside world, is that much more difficult.
I am seeing some attempts to rectify this, particularly at large technology companies. Agile Scalable Framework (or SAFe) is one of the new hot trends. It basically sticks the old PMP stuff like financials, risk management, forecasting, etc. on to Agile. I tried it many years ago at a poorly run organization and it kind of but not really worked. I have friends trying to implement it in different places, and I think they'll do well with it, but largely because they're Agilists to begin with.
Also, something I didn't go into much because it makes me sad is the transition from whatever you were before to Agile. It sucks. For everyone. I've been recruited for those kinds of gigs (and they pay a decent amount more than I make) but always turn it down. It's miserable. And it's something where you have to be really dedicated to it.
I have a good friend and former boss who is about to start a project doing Agile coaching for the Center for Medicare and Medicaid Services (CMS) here in the States. I suspect I'll end up working on it some (CMS is the closest thing we have to socialized medicine and I have a background in Healthcare and HIT), but I've already started reminding him how hard it is to shift big organizations.
One more thing to add, and that's that Agile isn't for everyone or every project, even within Agile firms. I was on a panel with a leading member of 18F, an organization within the US Government trying to bring Agile development and contracting and smart digital services to the government. Their sister agency in the UK is Government Digital Services. Both he and I (on a panel of four) were massive Agilists, but something that came up was whether Agile worked for O&M and maintenance/IT projects. We had different answers, but it roughly equated to "ummm...maybe?" Again, Agile isn't for everyone or everything.
We've complained for year about the compartmentalisation and silo mentality. People with no direct client contact developing their own little products & then wanting to charge the earth for it. We have to remind them that we look after the whole client and not just the tiny bit they are supplying.
In large organisations, Agile is pretty much doomed as it's nigh on impossible to get something that is appropriate across too wide a base.
Doesn't stop our bosses hiring these people and ploughing millions into them though. They all went on the same business management courses to tell them that's what they Should do!!
Agile, Waterfall, whatever you like. Get the requirements nailed down and things will run smoothly. Trouble with Agile is, unless it's done properly, the requirements piece is more likely to be sloppy so the end result is sloppy. You then need iterative changes to get it right which can be a headache for the Business. My experience anyway.
I know we had a thread a couple of months back about BA's - thought i'd start a thread for all those BA's/PO's/Developers/Scrum Masters out there (and i know there are a few) who have been sucked into the Agile world.
I am relatively new to Agile -maybe a years experience now primarily as developer/scrum master, and have achieved my CSM, and have just come off a course for writing Effective User Stories.
I am trying very seriously to move into the Agile World full-time now- seeing that job opportunities seem to be much more healthy within Agile than not.
I am also meeting up with one of the Agile Gurus from the States next month who is a regular Podcast writer for ThisAgileLife.com, and also have started reading a book called Scrum Mastery by Jeff Watts which is extremely good. , Too many I's - should maybe be starting some paragraphs with 'As a ' !
Whats your experience with Agile/Scrum? - and what has been your thoughts/experiences so far (maybe in comparison to Waterfall development)?.
Nope. Tried this in Google translate. Still nothing.
@SDAddick I'm pleased that you've found something that you enjoy and seem genuinely to have managed to get it to work in even the most demanding sectors.
I'm a wee bit older than you (unless the millennium started in 1966!!), but like to think that I have adapted to change over the years and I do pick up new things very quickly (unless spotted by a copper)!
I have always worked for Barclays and for the last 15 years looking after some of the biggest law firms in the world.
Now to the Agile part...we have teams and teams of these people throughout my building, working on projects all over the place. Most of what they do has a profound effect on people they wouldn't recognise if one of them walked up to them and smacked them on the arse with a banjo. They develop systems and pat themselves on the back, having consulted with each other on what someone else, they have never met, would want. A case in point is the payment system we currently use. Agile means we can update this with new widgets far quicker than we ever did before. Unfortunately, every time we do a weekend "refresh", it's a bit like engineering works on the railways...you know damn well that you're going to be fucked on the Monday morning.
They're getting there in our place now. They are actually talking to us and I have managed to get the head guy out to meet several of my clients who were under orders to use the same language they had previously used with me. They seem to be listening, but it shouldn't have taken this long for them to do that. Their argument is that our Senior Management (yep, we're working for different senior management) signed it off. Unfortunately, I'd like to use that banjo on our SMT too, as they haven't a freakin clue what the client actually wants either (there seems to be a link here for SMTs).
As it goes Agile, or any new system, is only ever going to be as good as the people who are running/implementing it. As good as the information that goes into building it and understanding that every action has a reaction and what you need to do to ensure that that's a reaction that you actually want.
Don't want to piss on anyone's parade, but a lot of us who have looked after people for a long time call that business as usual...its just about making sure that the right people get it and act on it.
McTel, yes, very fair, espcially that part. If you have good people, good things happen, and vice versa. Agile, as I think of it, is a great way to get more out of good people with empowerment and buy in. But if people are insular and isolated, Agile will not, on its own, change that. But what Agile can do (and here's where the Marxist in me comes out) is create a pseudo-democratic workplace in which employees have more of a say on what the company does, and that can lead to better productivity and creativity.
One thing I come across a fair amount is how well Agile scales, particularly to large organizations. And the answer is...from what I can tell not that great most of the time. There are a lot of reasons for that, and I think a big part of it is what sounds like is happening with you--large companies are compartmentalized so collaboration and cooperation with each other, let alone the outside world, is that much more difficult.
I am seeing some attempts to rectify this, particularly at large technology companies. Agile Scalable Framework (or SAFe) is one of the new hot trends. It basically sticks the old PMP stuff like financials, risk management, forecasting, etc. on to Agile. I tried it many years ago at a poorly run organization and it kind of but not really worked. I have friends trying to implement it in different places, and I think they'll do well with it, but largely because they're Agilists to begin with.
Also, something I didn't go into much because it makes me sad is the transition from whatever you were before to Agile. It sucks. For everyone. I've been recruited for those kinds of gigs (and they pay a decent amount more than I make) but always turn it down. It's miserable. And it's something where you have to be really dedicated to it.
I have a good friend and former boss who is about to start a project doing Agile coaching for the Center for Medicare and Medicaid Services (CMS) here in the States. I suspect I'll end up working on it some (CMS is the closest thing we have to socialized medicine and I have a background in Healthcare and HIT), but I've already started reminding him how hard it is to shift big organizations.
Took the words out me mouth.
If I had any fookin idea what you nerds are on about,
Agile, Waterfall, whatever you like. Get the requirements nailed down and things will run smoothly. Trouble with Agile is, unless it's done properly, the requirements piece is more likely to be sloppy so the end result is sloppy. You then need iterative changes to get it right which can be a headache for the Business. My experience anyway.
An excellent point, and my current project may be facing the reality of re-building a 20 year old system that no one quite understands how it should work (at least no one we currently have access to). It's problematic regardless of what methodology is used.
We've complained for year about the compartmentalisation and silo mentality. People with no direct client contact developing their own little products & then wanting to charge the earth for it. We have to remind them that we look after the whole client and not just the tiny bit they are supplying.
In large organisations, Agile is pretty much doomed as it's nigh on impossible to get something that is appropriate across too wide a base.
Doesn't stop our bosses hiring these people and ploughing millions into them though. They all went on the same business management courses to tell them that's what they Should do!!
I will be the first to admit, having been the victim of this, that Agile doesn't not fix shit management, and arguably compounds it. The thing I'd say to you is that what you're seeing is not indicative of the whole, even at large organizations.
Agile, Waterfall, whatever you like. Get the requirements nailed down and things will run smoothly. Trouble with Agile is, unless it's done properly, the requirements piece is more likely to be sloppy so the end result is sloppy. You then need iterative changes to get it right which can be a headache for the Business. My experience anyway.
Isnt that one of the principles of the Agile Manifesto?....Iterative process. Isnt the ability to 'inspect and adapt' and get feedback from the business within a short time frame one of the key plusses to Agile? - that way there is less chance of the project being canned after a year because management see no progress and thereby the focus has changed?
A colleague and I are attempting to create a small consultancy providing Agile services - we are chewing around with website names but cant nail one - any ideas? we were trying to encompass Agility,Agile,Transformation,Agile Done Well......etc. Any thoughts?
A colleague and I are attempting to create a small consultancy providing Agile services - we are chewing around with website names but cant nail one - any ideas? we were trying to encompass Agility,Agile,Transformation,Agile Done Well......etc. Any thoughts?
Just found this thread and spent the last 20 mins scrolling through it. Not got a fckxxg clue what you are all going on about. Roll on next Saturday when the football returns
A colleague and I are attempting to create a small consultancy providing Agile services - we are chewing around with website names but cant nail one - any ideas? we were trying to encompass Agility,Agile,Transformation,Agile Done Well......etc. Any thoughts?
Whatever you do, don't do what I did. I picked two really common words, which later occurred to me as meaning the same thing (... I'm an idiot, really.), which condemned me to an uphill battle when it came to the likes of SEO. I'll be filing with Companies House to change the name in the next couple of weeks I think. It's actually come at a decent time, as I'm redoing my webshit and trying to come up with something akin to an actual "brand".
It's just a ballache if you find yourself needing to change things like phone contracts, banking details, accountancy software, email addresses, insurance policies and so on. Not a great situation to find yourself in after 8 months, I dread to think about the mess I'd find myself in after any longer!
I had read quite a bit before incorporating the company, and every article said the same "take great care when deciding upon a name". Unfortunately, I needed to incorporate quickly as I was going to do some contracting to gain the capital to go it alone, and was offered a contract with a start pretty much immediately.
You probably wont be too interested, as I come from a pure tech/dev background, but if you want a catch-up over a beer or something then let me know. To be entirely honest I've often felt like I'm winging it over the past year, but I'm slowly starting to gain a decent vision. The idea is, like you, to offer consultancy services over technical matters (inc. team recruitment) whilst providing a SaaS product (log management with configurable rules for triggering automated alerts via SMS) as a credibility prop and source of interest. You can never know too many people though!
Agile, Agile, Agile. Never has one word been preached about so much, but misunderstood by so many. I count myself in that too, though..
I've worked in Agile environments as a Developer, and for a short period whilst running a DevOps team. These environments have ranged from enterprise software houses, healthcare software companies, startups and a multinational electronics company. Despite every one of these places claiming to be agile, none of them has actually interpreted what Agile is in the same way.
The common theme from a development point of view has been Scrum though; so iterative sprints, backlog grooming, short feedback loops and a degree of self-management. In fact, I have a copy of The Scrum Guide on my desk as I'm going to try and get certified by the end of the year, just to gain some self-assurance more than anything else.
The Negatives
I'd argue the biggest barrier to working with these goals in mind is that some places are simply unable to change. Specifically, corporate environments where it takes several levels of approval just to purchase a software license, or to provision a new machine, or even to approve a minor change to functionality.
These environments are, in my mind, doomed to fail without a drastic change in their attitudes that permeates top down. An interesting real life example here is the TalkTalk hack, and it's one I've used in infosec talks. Having interviewed a Developer from TalkTalk, I was struck by how he described his duties as "being a keyboard drone", and how the flow of information was very much one way. This ties up with how absolutely stupid the vulnerability that was exploited was (something that a junior developer should've been able to see) and Dido Harding's moronic statements to the press which demonstrated that there was no technical input at a senior level. This is an awesome example of the costs associated with having a development/engineering team that is operating in an environment that isn't engineered correctly itself.
Another issue is that there are environments where you bring in these fancy new ideas and they are subsequently embraced too heavily! Since doing contract work, I've worked in two offices where the morning stand-up takes approximately 25-30 minutes, for a team of 7 or so. Alas, that's what happens when you have Dev(/Ops) guys explaining the previous day's work at a codebase level, and Product guys explaining every client interaction they had.
The sad thing is, the longer these stand-ups go on, the less I think anyone in the team knows as to what's actually going on - be that due to over information, or pure and simple misinformation.
Like any other methodology or technique, you also rely on the individuals involved adhering to it correctly. The healthcare company I worked at developed a package that did EMR (Electronic Medical Records), PACS (Picture Archiving and Communication), Billing and Invoicing and automated clinical workflows. Although we worked to two-week sprints, these often turned into "marathons" when a deadline was looming. The process would go out of the window, and a sprint would continue until the work was completed: symptomatic of poor planning. When implementing some features it wasn't uncommon to see a 2-week sprint hit the 4-week mark.
This wasn't a lack of education - everyone involved knew this was wrong, but it was an example of the business placing its needs above that of the process. This obviously caused issues for subsequent sprints, and set a precedent whereby the process wasn't too important. Not great.
The Positives
I genuinely don't think I could do my job without some form of agile methodology. I've worked in one place where things were done in a traditional waterfall style, and I simply couldn't manage it: estimates were way off, pre-launch modifications were huge and it became something of a "death march".
It's important not to underestimate the piece of mind that it provides to project stakeholders too; suddenly they have visibility of every aspect of the process. They can see the tempo/rate of the work being conducted, and more importantly, they have awareness of any impending issues.
A result of the increased visibility of what people are actually working on, there is an additional degree of protection against lazy bastards, and in an ideal situation, it can also provide protection for overworked members of staff. I do think this can be detrimental to members of staff with low confidence, however that is an issue that goes back to mentoring and personal development - way out of scope with regards to this topic! (I'm quite opinionated about that subject.)
There's also some brilliant tooling available for teams working this way too, for instance - it's difficult to find a poor fecker that hasn't had to use JIRA before. On the flip side, I could knock together a Trello board that would be suitable in about 10 mouse clicks. When you have tried and trusted tools that are designed exactly around your working practices, then suddenly life becomes even easier. (Not quite sure this is true for JIRA though, I don't like it.)
Conclusion
These observations aren't even about Agile (or Scrum specifically) - but they're worth thinking about:
Any methodology needs to be embraced and encouraged from the top, and this involves educating those at the top
Everyone involved needs clearly defined terms and/or expectations: there are far too many deviations from common principles
If a process is to work, then it needs to be adhered to and respected. Once it fails, it will fail repeatedly IMO.
The additional oversight and visibility it provides is excellent and should be taken advantage of
It's advantages should extend beyond productivity, into morale and security too
I would say it's not a silver bullet that is going to transform poor quality members of staff into super productive high-flyers, but with the right people in the mix it can certainly iron out inefficiencies and provide a boost to morale.
I may have more to say when I've had a bit of a think, but I realise I posted in this thread a few weeks ago when I was drunkenly eating Chinese food in Chinatown - yet I never did follow it up.
Agile, Waterfall, whatever you like. Get the requirements nailed down and things will run smoothly. Trouble with Agile is, unless it's done properly, the requirements piece is more likely to be sloppy so the end result is sloppy. You then need iterative changes to get it right which can be a headache for the Business. My experience anyway.
This. Too many people I've ran into think that agile is an excuse to start development before you have requirements.
Agile, Waterfall, whatever you like. Get the requirements nailed down and things will run smoothly. Trouble with Agile is, unless it's done properly, the requirements piece is more likely to be sloppy so the end result is sloppy. You then need iterative changes to get it right which can be a headache for the Business. My experience anyway.
This. Too many people I've ran into think that agile is an excuse to start development before you have requirements.
Surely the requirements are the Acceptance criteria from the User Story.?
I consulted at a huge financial services company last year who were trying to be Agile.
One morning I walked in to the HR area and half the desks were missing. Apparently they'd decided to be 'agile' by allowing people to work at a desk or standing. The only problem was they'd neglected to factor in that everyone had wyse terminals and required desks.
The sheer panic of the Technology teams when half of HR walked on to their floor will stay with me forever.
Agile, Waterfall, whatever you like. Get the requirements nailed down and things will run smoothly. Trouble with Agile is, unless it's done properly, the requirements piece is more likely to be sloppy so the end result is sloppy. You then need iterative changes to get it right which can be a headache for the Business. My experience anyway.
This. Too many people I've ran into think that agile is an excuse to start development before you have requirements.
Surely the requirements are the Acceptance criteria from the User Story.?
Agile, Waterfall, whatever you like. Get the requirements nailed down and things will run smoothly. Trouble with Agile is, unless it's done properly, the requirements piece is more likely to be sloppy so the end result is sloppy. You then need iterative changes to get it right which can be a headache for the Business. My experience anyway.
This. Too many people I've ran into think that agile is an excuse to start development before you have requirements.
Surely the requirements are the Acceptance criteria from the User Story.?
Note to self, do not visit Mendinca In Asdas' chemist.
I read through this thread without really knowing what people were in about. If Agile means an IT developer gets off their arse, speaks to the users, helps them to work out what they really want and then builds and tests it in stages, well that sounds like something that should be happening.
IT projects where you spend 3 years developing a spec pretty much blind as far as the user is concenrned and then IT Disappears for a year and then comes back with 'this is what you specified guys' suck.
Not only will the requirements have changed, but the users, not being trained in change or IT, will almost certainly have got the start of he spec wrong and then the whole thing is a pile of rubbish.
The scrum stuff sounds a bit like a fad dressing up a requirement. weekly or bi-weekly catchups on progress must be right, do they need a sprint, scrum and scrum master?
I consulted at a huge financial services company last year who were trying to be Agile.
One morning I walked in to the HR area and half the desks were missing. Apparently they'd decided to be 'agile' by allowing people to work at a desk or standing. The only problem was they'd neglected to factor in that everyone had wyse terminals and required desks.
The sheer panic of the Technology teams when half of HR walked on to their floor will stay with me forever.
That's not Agile Methodology though, that's a culture change that probably got dressed up as Agile because Agile is a buzzword and the company wanted to look like a Silicon Valley company.
Regarding starting things without requirements, I completely agree. But Agile should put less strain on the up-front requirements and more emphasis on working on things with users as they're being built. Pretty much every project I've worked on it's been the case where if you just ask people what they want from a system out of context you get mediocre answers. But if you ask enough to start building things then show them and let them use it the outcomes and efficiencies are far greater.
@SurvivaloftheFittest That's not to trivialize or be dismissive of your complaint, I absolutely get it, and it's the same with McTel's posts, I'm just try to point out that's not Agile, it's just shitty leadership. I think I've said before that Agile can really compound the problems within companies when not done right. Sometimes that's good, sometimes it forces some real soul searching, but a lot of the time it just makes everything worse.
Comments
And cheers El Presidente.
I'm a wee bit older than you (unless the millennium started in 1966!!), but like to think that I have adapted to change over the years and I do pick up new things very quickly (unless spotted by a copper)!
I have always worked for Barclays and for the last 15 years looking after some of the biggest law firms in the world.
Now to the Agile part...we have teams and teams of these people throughout my building, working on projects all over the place. Most of what they do has a profound effect on people they wouldn't recognise if one of them walked up to them and smacked them on the arse with a banjo. They develop systems and pat themselves on the back, having consulted with each other on what someone else, they have never met, would want. A case in point is the payment system we currently use. Agile means we can update this with new widgets far quicker than we ever did before. Unfortunately, every time we do a weekend "refresh", it's a bit like engineering works on the railways...you know damn well that you're going to be fucked on the Monday morning.
They're getting there in our place now. They are actually talking to us and I have managed to get the head guy out to meet several of my clients who were under orders to use the same language they had previously used with me. They seem to be listening, but it shouldn't have taken this long for them to do that. Their argument is that our Senior Management (yep, we're working for different senior management) signed it off. Unfortunately, I'd like to use that banjo on our SMT too, as they haven't a freakin clue what the client actually wants either (there seems to be a link here for SMTs).
As it goes Agile, or any new system, is only ever going to be as good as the people who are running/implementing it. As good as the information that goes into building it and understanding that every action has a reaction and what you need to do to ensure that that's a reaction that you actually want.
Don't want to piss on anyone's parade, but a lot of us who have looked after people for a long time call that business as usual...its just about making sure that the right people get it and act on it.
One thing I come across a fair amount is how well Agile scales, particularly to large organizations. And the answer is...from what I can tell not that great most of the time. There are a lot of reasons for that, and I think a big part of it is what sounds like is happening with you--large companies are compartmentalized so collaboration and cooperation with each other, let alone the outside world, is that much more difficult.
I am seeing some attempts to rectify this, particularly at large technology companies. Agile Scalable Framework (or SAFe) is one of the new hot trends. It basically sticks the old PMP stuff like financials, risk management, forecasting, etc. on to Agile. I tried it many years ago at a poorly run organization and it kind of but not really worked. I have friends trying to implement it in different places, and I think they'll do well with it, but largely because they're Agilists to begin with.
Also, something I didn't go into much because it makes me sad is the transition from whatever you were before to Agile. It sucks. For everyone. I've been recruited for those kinds of gigs (and they pay a decent amount more than I make) but always turn it down. It's miserable. And it's something where you have to be really dedicated to it.
I have a good friend and former boss who is about to start a project doing Agile coaching for the Center for Medicare and Medicaid Services (CMS) here in the States. I suspect I'll end up working on it some (CMS is the closest thing we have to socialized medicine and I have a background in Healthcare and HIT), but I've already started reminding him how hard it is to shift big organizations.
In large organisations, Agile is pretty much doomed as it's nigh on impossible to get something that is appropriate across too wide a base.
Doesn't stop our bosses hiring these people and ploughing millions into them though. They all went on the same business management courses to tell them that's what they Should do!!
Tried this in Google translate.
Still nothing.
If I had any fookin idea what you nerds are on about,
Isnt the ability to 'inspect and adapt' and get feedback from the business within a short time frame one of the key plusses to Agile? - that way there is less chance of the project being canned after a year because management see no progress and thereby the focus has changed?
Any thoughts?
Not got a fckxxg clue what you are all going on about.
Roll on next Saturday when the football returns
It's just a ballache if you find yourself needing to change things like phone contracts, banking details, accountancy software, email addresses, insurance policies and so on. Not a great situation to find yourself in after 8 months, I dread to think about the mess I'd find myself in after any longer!
I had read quite a bit before incorporating the company, and every article said the same "take great care when deciding upon a name". Unfortunately, I needed to incorporate quickly as I was going to do some contracting to gain the capital to go it alone, and was offered a contract with a start pretty much immediately.
You probably wont be too interested, as I come from a pure tech/dev background, but if you want a catch-up over a beer or something then let me know. To be entirely honest I've often felt like I'm winging it over the past year, but I'm slowly starting to gain a decent vision. The idea is, like you, to offer consultancy services over technical matters (inc. team recruitment) whilst providing a SaaS product (log management with configurable rules for triggering automated alerts via SMS) as a credibility prop and source of interest. You can never know too many people though!
I've worked in Agile environments as a Developer, and for a short period whilst running a DevOps team. These environments have ranged from enterprise software houses, healthcare software companies, startups and a multinational electronics company. Despite every one of these places claiming to be agile, none of them has actually interpreted what Agile is in the same way.
The common theme from a development point of view has been Scrum though; so iterative sprints, backlog grooming, short feedback loops and a degree of self-management. In fact, I have a copy of The Scrum Guide on my desk as I'm going to try and get certified by the end of the year, just to gain some self-assurance more than anything else.
The Negatives
I'd argue the biggest barrier to working with these goals in mind is that some places are simply unable to change. Specifically, corporate environments where it takes several levels of approval just to purchase a software license, or to provision a new machine, or even to approve a minor change to functionality.
These environments are, in my mind, doomed to fail without a drastic change in their attitudes that permeates top down. An interesting real life example here is the TalkTalk hack, and it's one I've used in infosec talks. Having interviewed a Developer from TalkTalk, I was struck by how he described his duties as "being a keyboard drone", and how the flow of information was very much one way. This ties up with how absolutely stupid the vulnerability that was exploited was (something that a junior developer should've been able to see) and Dido Harding's moronic statements to the press which demonstrated that there was no technical input at a senior level. This is an awesome example of the costs associated with having a development/engineering team that is operating in an environment that isn't engineered correctly itself.
Another issue is that there are environments where you bring in these fancy new ideas and they are subsequently embraced too heavily! Since doing contract work, I've worked in two offices where the morning stand-up takes approximately 25-30 minutes, for a team of 7 or so. Alas, that's what happens when you have Dev(/Ops) guys explaining the previous day's work at a codebase level, and Product guys explaining every client interaction they had.
The sad thing is, the longer these stand-ups go on, the less I think anyone in the team knows as to what's actually going on - be that due to over information, or pure and simple misinformation.
Like any other methodology or technique, you also rely on the individuals involved adhering to it correctly. The healthcare company I worked at developed a package that did EMR (Electronic Medical Records), PACS (Picture Archiving and Communication), Billing and Invoicing and automated clinical workflows. Although we worked to two-week sprints, these often turned into "marathons" when a deadline was looming. The process would go out of the window, and a sprint would continue until the work was completed: symptomatic of poor planning. When implementing some features it wasn't uncommon to see a 2-week sprint hit the 4-week mark.
This wasn't a lack of education - everyone involved knew this was wrong, but it was an example of the business placing its needs above that of the process. This obviously caused issues for subsequent sprints, and set a precedent whereby the process wasn't too important. Not great.
The Positives
I genuinely don't think I could do my job without some form of agile methodology. I've worked in one place where things were done in a traditional waterfall style, and I simply couldn't manage it: estimates were way off, pre-launch modifications were huge and it became something of a "death march".
It's important not to underestimate the piece of mind that it provides to project stakeholders too; suddenly they have visibility of every aspect of the process. They can see the tempo/rate of the work being conducted, and more importantly, they have awareness of any impending issues.
A result of the increased visibility of what people are actually working on, there is an additional degree of protection against lazy bastards, and in an ideal situation, it can also provide protection for overworked members of staff. I do think this can be detrimental to members of staff with low confidence, however that is an issue that goes back to mentoring and personal development - way out of scope with regards to this topic! (I'm quite opinionated about that subject.)
There's also some brilliant tooling available for teams working this way too, for instance - it's difficult to find a poor fecker that hasn't had to use JIRA before. On the flip side, I could knock together a Trello board that would be suitable in about 10 mouse clicks. When you have tried and trusted tools that are designed exactly around your working practices, then suddenly life becomes even easier. (Not quite sure this is true for JIRA though, I don't like it.)
Conclusion
These observations aren't even about Agile (or Scrum specifically) - but they're worth thinking about:
- Any methodology needs to be embraced and encouraged from the top, and this involves educating those at the top
- Everyone involved needs clearly defined terms and/or expectations: there are far too many deviations from common principles
- If a process is to work, then it needs to be adhered to and respected. Once it fails, it will fail repeatedly IMO.
- The additional oversight and visibility it provides is excellent and should be taken advantage of
- It's advantages should extend beyond productivity, into morale and security too
I would say it's not a silver bullet that is going to transform poor quality members of staff into super productive high-flyers, but with the right people in the mix it can certainly iron out inefficiencies and provide a boost to morale.I may have more to say when I've had a bit of a think, but I realise I posted in this thread a few weeks ago when I was drunkenly eating Chinese food in Chinatown - yet I never did follow it up.
One morning I walked in to the HR area and half the desks were missing. Apparently they'd decided to be 'agile' by allowing people to work at a desk or standing. The only problem was they'd neglected to factor in that everyone had wyse terminals and required desks.
The sheer panic of the Technology teams when half of HR walked on to their floor will stay with me forever.
I read through this thread without really knowing what people were in about. If Agile means an IT developer gets off their arse, speaks to the users, helps them to work out what they really want and then builds and tests it in stages, well that sounds like something that should be happening.
IT projects where you spend 3 years developing a spec pretty much blind as far as the user is concenrned and then IT Disappears for a year and then comes back with 'this is what you specified guys' suck.
Not only will the requirements have changed, but the users, not being trained in change or IT, will almost certainly have got the start of he spec wrong and then the whole thing is a pile of rubbish.
The scrum stuff sounds a bit like a fad dressing up a requirement. weekly or bi-weekly catchups on progress must be right, do they need a sprint, scrum and scrum master?
Maybe it helps.
Regarding starting things without requirements, I completely agree. But Agile should put less strain on the up-front requirements and more emphasis on working on things with users as they're being built. Pretty much every project I've worked on it's been the case where if you just ask people what they want from a system out of context you get mediocre answers. But if you ask enough to start building things then show them and let them use it the outcomes and efficiencies are far greater.
I've not, but I hear it's lovely