Discussion
They employ them where I work. As far as I can tell their job is to oversee 'agile' teams to ensure that everything is kept moving along and adheres to agile methodology. I quite fancy doing the qualification myself as it's relevant to all sorts of roles that I'm interested in. It seems to be popular in the tech sector or in any organisation that has a tech element. There may be other applications too though I'll leave it to those better qualified to answer further.
It's the de facto standard for developing software products nowadays. Very difficult to do iterative / incremental development when hardware's involved. It's also /most/ relevant pre-market fit, building prototypes and getting stakeholder feedback.
The whole agile movement is very sensible and lightweight, but the circus around it is horrific. Like crossfit and vegan level of religiousosity.
Important to remember it was also invented by engineers for their own benefit. So there are aspects of the business side of things that are under represented. Other potential downside: developers stop frequently to go validate.
It's definitely worth approaching with an open mind.
The whole agile movement is very sensible and lightweight, but the circus around it is horrific. Like crossfit and vegan level of religiousosity.
Important to remember it was also invented by engineers for their own benefit. So there are aspects of the business side of things that are under represented. Other potential downside: developers stop frequently to go validate.
It's definitely worth approaching with an open mind.
If you are coming from a PRINCE2 back ground then yes it probably would seem quite alien.
It can work very well but as PBDirector has hit the nail on the head people are too dogmatic about it. I have worked in software development for years. In my team now we use a hybrid system. We have basically taken the best bits from SCRUM (self managed work load, task boards, defined sprints) and dumped some of the less useful bits.
The biggest failure I have see with SCRUM is when the IT teams get it and the business doesn't. I have seen it work very well in large organisation because all the business people and PMs had been trained. So there was a product owner who didn't work in IT but he got the whole process and it worked well
It can work very well but as PBDirector has hit the nail on the head people are too dogmatic about it. I have worked in software development for years. In my team now we use a hybrid system. We have basically taken the best bits from SCRUM (self managed work load, task boards, defined sprints) and dumped some of the less useful bits.
The biggest failure I have see with SCRUM is when the IT teams get it and the business doesn't. I have seen it work very well in large organisation because all the business people and PMs had been trained. So there was a product owner who didn't work in IT but he got the whole process and it worked well
^nice, agreed.
Seeing as you've opened Pandora's box, and it's early in the thread, I'll make some bold sweeping statements that can be shot down in flames.
In the context of software product management, agile works. It's the best system yet developed. But it will almost always require customisation for your needs. It requires everyone to be engaged and play their part. It very quickly shines a light on anybody or any process that accidentally or wantonly interferes or fails to do its part. For this reason alone, it's doomed to fail in companies where the politics of power prevail. If you're a cog in a giant machine who wants to, or is told to "do agile" it can be hell; because you've no authority to hire, fire or coerce people into action. If you're the <ahem> powerfully built leader of such an organisation, then it can be a dream. But not always and not for everyone.
There you are, have at it you miserable contrarian bunch.
Seeing as you've opened Pandora's box, and it's early in the thread, I'll make some bold sweeping statements that can be shot down in flames.
In the context of software product management, agile works. It's the best system yet developed. But it will almost always require customisation for your needs. It requires everyone to be engaged and play their part. It very quickly shines a light on anybody or any process that accidentally or wantonly interferes or fails to do its part. For this reason alone, it's doomed to fail in companies where the politics of power prevail. If you're a cog in a giant machine who wants to, or is told to "do agile" it can be hell; because you've no authority to hire, fire or coerce people into action. If you're the <ahem> powerfully built leader of such an organisation, then it can be a dream. But not always and not for everyone.
There you are, have at it you miserable contrarian bunch.
We're moving in that Scrum direction (Scrummish? Scrummy?). Agree with the sentiments expressed so far.
Our Scrum master keeps everybody, but everybody, the f
k far away from the dev guys in the scrum, so they have no distractions/conflicts in doing their work. In ever daily he asks each dev "What did you do yesterday?", "What do you intend to do today?", "What do you need me to do for you?"
The devs love it.
Our Scrum master keeps everybody, but everybody, the f
k far away from the dev guys in the scrum, so they have no distractions/conflicts in doing their work. In ever daily he asks each dev "What did you do yesterday?", "What do you intend to do today?", "What do you need me to do for you?"The devs love it.
PBDirector said:
^nice, agreed.
Seeing as you've opened Pandora's box, and it's early in the thread, I'll make some bold sweeping statements that can be shot down in flames.
In the context of software product management, agile works. It's the best system yet developed. But it will almost always require customisation for your needs. It requires everyone to be engaged and play their part. It very quickly shines a light on anybody or any process that accidentally or wantonly interferes or fails to do its part. For this reason alone, it's doomed to fail in companies where the politics of power prevail. If you're a cog in a giant machine who wants to, or is told to "do agile" it can be hell; because you've no authority to hire, fire or coerce people into action. If you're the <ahem> powerfully built leader of such an organisation, then it can be a dream. But not always and not for everyone.
There you are, have at it you miserable contrarian bunch.
Definitely agree with the religiousosity of the circus around the whole agile concept. Some people buy in heart & soul to the terminology and follow the process rigidly which goes against what most devs who just want to get the job done. Taking an open minded approach and being flexible with the agile framework can bring about some improvements.Seeing as you've opened Pandora's box, and it's early in the thread, I'll make some bold sweeping statements that can be shot down in flames.
In the context of software product management, agile works. It's the best system yet developed. But it will almost always require customisation for your needs. It requires everyone to be engaged and play their part. It very quickly shines a light on anybody or any process that accidentally or wantonly interferes or fails to do its part. For this reason alone, it's doomed to fail in companies where the politics of power prevail. If you're a cog in a giant machine who wants to, or is told to "do agile" it can be hell; because you've no authority to hire, fire or coerce people into action. If you're the <ahem> powerfully built leader of such an organisation, then it can be a dream. But not always and not for everyone.
There you are, have at it you miserable contrarian bunch.
I've been scrum master for a team since last September working on safety critical programmes (DO178-B level A&B) and for sure as a team we work together better now. Stand ups and regular review retrospectives have improved communication greatly and made the team more able to review the processes & procedures. However, as you say it need customisation. As one of the first teams on site to take up agile we have the freedom to bend the framework to match existing procedures which we due to the nature of the project have quite rigid procedure. Without that freedom we would have given up on agile within weeks.
The powers that been are happy at the moment to keep their noses out which is probably helping the most. The team has been together for a while prior to taking on agile so hopefully politics can be kept at bay. Managment is hoping savings can be made however I've not seem any so far. What we have noticed is an improvement in qualitiy of work being completed, maybe come the end of the project we'll see savings through reduced review & re-work cycles. Without clear savings I'd imagine it will be abandoned & chalked up to experience.
The religiosity is painful and completely in contradiction to the spirit of pragmatism that in my opinion agile is all about. The core ideas are so simple to grasp if you've had any experience working on a software project. The idea of sending people on approved training programmes to be tutored in this stuff and tit around with lego seems daft to me. Learn by doing. Teach the team by having someone familiar with the approach help oversee the first few sprints. You don't need more than that, and you're less likely to put people's backs up.
midget_ad said:
Managment is hoping savings can be made however I've not seem any so far. What we have noticed is an improvement in qualitiy of work being completed, maybe come the end of the project we'll see savings through reduced review & re-work cycles. Without clear savings I'd imagine it will be abandoned & chalked up to experience.
And this is where the alarm bells start ringing. I don't think anyone (who knows what they're talking about) has ever said agile will save money. What it will do is stop[1] the situation where you have a team toiling away for a number of (chronological) years, who then release the product and it tanks in the market place. It tanks because either they didn't get market feedback and they'd built the wrong thing, or because during the gap between somebody writing the requirements/ specification and delivery the market changed or a competitor brought out a different product, or whatever. [that's possibly what midget_ad was implying in this post, I can't quite tell]The way I had it explained to me was if you do the following stages: SPECIFY, DEVELOP, TEST in order, then all the testing is done at the end, and it's the thing that gets cut when the DEVELOP inevitably takes longer than you thought it were. So by running your project like that, you're explicitly stating that you value TESTing (i.e. quality) least.
That made perfect sense to me, and along with the idea of continuously releasing something and getting incremental feedback from stakeholders and potential customers, and the idea that it makes it very clear immediately who's the useless/ political ones in the company, then I was sold.
I'll throw another sweeping statement out there: going forwards, if you want to recruit good software developers[2] then they're going to expect you to provide an agile environment, with everyone including all of the management bought into it. Without it, you're picking up the not-so-good developers, or people who need CV experience then they'll move on.
1. clearly it won't stop it. but it might help reduce the likelihood
2. I'm not including embedded/ C++, it's a different culture, but everyone else.
Edited by PBDirector on Friday 20th May 08:32
ATG said:
The idea of sending people on approved training programmes to be tutored in this stuff and tit around with lego seems daft to me. Learn by doing. Teach the team by having someone familiar with the approach help oversee the first few sprints. You don't need more than that, and you're less likely to put people's backs up.
I want to agree with this. I think I do agree with it in my head. But I believe there is value in having your people (all) go out to someone external to learn best practice, and then come back into the company and do the process you've described (possibly with a consultant).It's proximity bias - people don't take the advice of the people closest to them.
PBDirector said:
I want to agree with this. I think I do agree with it in my head. But I believe there is value in having your people (all) go out to someone external to learn best practice, and then come back into the company and do the process you've described (possibly with a consultant).
It's proximity bias - people don't take the advice of the people closest to them.
I'd agree with this. Particularly as the critical people to get "on board" with scrum are the business - the product owners and management. Who are the least likely to listen to developers or anyone perceived as being "techie" (which would include a scrum master).It's proximity bias - people don't take the advice of the people closest to them.
Whereas they will listen to an external overpaid "consultancy" :-)
PBDirector said:
It's proximity bias - people don't take the advice of the people closest to them.
massive issue in the NHS, or perhaps it;s the fact that the team who know the service will come up wuith the answer that is best for the service not the pre-ordained outcome required by the shiny arses ... taking that into any setting - if there is someone to stop that happening there will be benefits to the delivered product / system
PBDirector said:
And this is where the alarm bells start ringing. I don't think anyone (who knows what they're talking about) has ever said agile will save money. What it will do is stop[1] the situation where you have a team toiling away for a number of (chronological) years, who then release the product and it tanks in the market place. It tanks because either they didn't get market feedback and they'd built the wrong thing, or because during the gap between somebody writing the requirements/ specification and delivery the market changed or a competitor brought out a different product, or whatever. [that's possibly what midget_ad was implying in this post, I can't quite tell]
The way I had it explained to me was if you do the following stages: SPECIFY, DEVELOP, TEST in order, then all the testing is done at the end, and it's the thing that gets cut when the DEVELOP inevitably takes longer than you thought it were. So by running your project like that, you're explicitly stating that you value TESTing (i.e. quality) least.
That made perfect sense to me, and along with the idea of continuously releasing something and getting incremental feedback from stakeholders and potential customers, and the idea that it makes it very clear immediately who's the useless/ political ones in the company, then I was sold.
I'll throw another sweeping statement out there: going forwards, if you want to recruit good software developers[2] then they're going to expect you to provide an agile environment, with everyone including all of the management bought into it. Without it, you're picking up the not-so-good developers, or people who need CV experience then they'll move on.
1. clearly it won't stop it. but it might help reduce the likelihood
2. I'm not including embedded/ C++, it's a different culture, but everyone else.
I'm in the embedded world so it's pretty new to all of us. None of the developers were expecting agile when we started but most are receptive to the change. Whether it's because they value the approach or are using this as experience for their CVs is to be seen.The way I had it explained to me was if you do the following stages: SPECIFY, DEVELOP, TEST in order, then all the testing is done at the end, and it's the thing that gets cut when the DEVELOP inevitably takes longer than you thought it were. So by running your project like that, you're explicitly stating that you value TESTing (i.e. quality) least.
That made perfect sense to me, and along with the idea of continuously releasing something and getting incremental feedback from stakeholders and potential customers, and the idea that it makes it very clear immediately who's the useless/ political ones in the company, then I was sold.
I'll throw another sweeping statement out there: going forwards, if you want to recruit good software developers[2] then they're going to expect you to provide an agile environment, with everyone including all of the management bought into it. Without it, you're picking up the not-so-good developers, or people who need CV experience then they'll move on.
1. clearly it won't stop it. but it might help reduce the likelihood
2. I'm not including embedded/ C++, it's a different culture, but everyone else.
Edited by PBDirector on Friday 20th May 08:32
I feel that 'anyone who knows what they're talking about' does not equal some of our management. To them agile is a magic wand leading to savings without much/ any understanding of what it is.Thankfully we can keep them at arms length & we have a line manager who has a good understanding of agile to prevent any interference.
The project is a significant update to existing software for which we provide the hardware also. While we don't have to worry about competition the customer has a habit of modifying requirements multiple times at any stage. Now we can manage these changes into increments and communicate better how requirements changes will impact deadlines.
As a team we see it in a similar light. In previous projects it was always testing which took the hit. For certification all the testing has to be done regardless but smaller non-functional issues end up being raised in problem reports and pushed to future developments. Now issues get fixed with each increment, meaning better quality product out the door.
I'm a qualified Scrum Master but only because the business put all of us BA's on the course in case they need to increase the number of Scrum Teams in the future
We've only been agile for a short time but so far its working very well, the devs love it, I love it as a BA as my documentation has more than halved with no discernible decrease in quality of SW delivered or requirements miseed
It took a while to get the business onside but some Product Owner training and they are now fully onboard as well
We've only been agile for a short time but so far its working very well, the devs love it, I love it as a BA as my documentation has more than halved with no discernible decrease in quality of SW delivered or requirements miseed
It took a while to get the business onside but some Product Owner training and they are now fully onboard as well
I would expect the course to cover your question quite early on, hopefully it has by now.
I'm a Certified Scrum Master and used a Scrum based approach for a few years on a range of software development projects. In 20 years in software I've previous experience of Chaotic/Heroic projects, RUP, DSDM and Prince.
Scrum works well where Prince does not, where Prince is too slow or heavy weight or expensive. Those situations where the requirements are uncertain or subject to rapid evolution, were quickly delivering the the most valuable feature is more important than getting all features absolute complete and compressive. Scrum places value incremental deliver and improvement.
The real difference between Scrum and Prince is what is varied. In Prince that will be Timescale or Cost. In Scrum the Timescale absolutely fixed and Cost pretty fixed and scope or features is flexed. Scrum is in many ways a response to the problems Fred Brooks identifies in Mythical Man-Month with traditional project management approaches.
To get the best from Scrum, I recommend it is used with Specification by Example / Behaviour Driven Development and Continuous Integration & Testing.
I'm a Certified Scrum Master and used a Scrum based approach for a few years on a range of software development projects. In 20 years in software I've previous experience of Chaotic/Heroic projects, RUP, DSDM and Prince.
Scrum works well where Prince does not, where Prince is too slow or heavy weight or expensive. Those situations where the requirements are uncertain or subject to rapid evolution, were quickly delivering the the most valuable feature is more important than getting all features absolute complete and compressive. Scrum places value incremental deliver and improvement.
The real difference between Scrum and Prince is what is varied. In Prince that will be Timescale or Cost. In Scrum the Timescale absolutely fixed and Cost pretty fixed and scope or features is flexed. Scrum is in many ways a response to the problems Fred Brooks identifies in Mythical Man-Month with traditional project management approaches.
To get the best from Scrum, I recommend it is used with Specification by Example / Behaviour Driven Development and Continuous Integration & Testing.
Edited by 4x4Tyke on Friday 20th May 16:01
944fan said:
... and dumped some of the less useful bits.
Scrum is already pretty light weight process, paired down to the minimum; so I'm interested in what you considered 'less useful'.944fan said:
So there was a product owner who didn't work in IT but he got the whole process and it worked well
You are right, getting the product owner to engage at all times is critical.I'm resurrecting the thread as I've been exposed to a degree of scrum at my last place of work since this was last updated. I found it very enjoyable working in a scrum team, the process seems to have great clarity. What is expected of you is very clear and I love that you have daily "stand-ups" to report what you've done since the last stand-up and then set your objectives for the next one - everything's so simple and clear. I'd be happy to be in a job where I was working this way all the time. Another thing I love is that agile very quickly exposes people who aren't adding value. I spent a lot of time in an environment where frothy, buzzword-spouting, self-promoting brownnosers always got the breaks and the recognition, purely because they were adept at knowing how the people at the top liked their leg rubbing, so it's great to work with a methodology where people like that are quickly exposed because they're not actually doing anything of substance, while quiet, introverted, hardworking people like me who prefer to let their work do the talking finally get to thrive. Also, I always hated the culture of having a line manager breathing down my neck and agile removes that element. You have your stand-up, go away with your objectives and work on fulfilling them, then report back the next morning. It takes away the element of everything feeling personal like it does when you have a conventional line manager relationship.
Anyway, the OH and I are working on a project which will soon require us to manage a dev team, so we both want to do scrum master courses. What's the industry standard these days? It's easy to find plenty of courses on Google but I guess anyone can set up offering them. What is the definitive qualification and who are the best providers?
Anyway, the OH and I are working on a project which will soon require us to manage a dev team, so we both want to do scrum master courses. What's the industry standard these days? It's easy to find plenty of courses on Google but I guess anyone can set up offering them. What is the definitive qualification and who are the best providers?
Gassing Station | Jobs & Employment Matters | Top of Page | What's New | My Stuff