Experience of Digital and Agile working?
Discussion
I've over 10 years experience in agile development dating back to when it was called iterative development and we used RUPP. I was the Automation lead on a UK Agile award winning project and I'm a certified Scrum Master. There are other agile approaches but Scrum is predominant at the moment.
Many teams and organisations claim they are 'Agile' when they are not. The biggest tell for this is do they use agile as a noun or a verb. "We use the Agile process" (wrong) or "we do x to be agile" (correct).
An agile approach is appropriate where the requirements are ill defined or subject to changing business circumstances. Requirements are expressed in collections of Stories and the main difference here is scope. A Story has very tightly defined scope and clear value. Stories are grouped into a collection we call an Epic with a single Theme e.g. Invoicing, Returns. Stories are also very similar to Use-cases.
Typically in a waterfall development the requirements are fixed and the two variables that flex are time or cost. In an agile approach we tightly fix the time-scale, called a Timebox or Sprint and flex the scope. We continually re-prioritise the stories to focus on highest value stories next. If a story is too big to be included in the Sprint, it is subject to the conventional techniques of functional decomposition and a separation of concerns.
Time-boxes allow the team, to regularly deliver a small piece of production quality of work for review by the product owner. These regular retrospectives also give the team an opportunity to review how they do things to look for improvements to working practices. Similar to Kaizen or continuous improvement in manufacturing.
Scrum is effective, but not easy, it will require significant changes in how you think, your processes and how you prioritise things. We call this transformation, in the maths sense, because we change the overall shape of the processes but do not remove any important pieces.
You can learn more about the actual how use Scrum at https://www.scrumalliance.org/
Some related and over lapping ideas:
Test/Feature/Behaviour driven development.
Lean Manufacturing and Just in Time deliver.
Continuous improvement.
Many teams and organisations claim they are 'Agile' when they are not. The biggest tell for this is do they use agile as a noun or a verb. "We use the Agile process" (wrong) or "we do x to be agile" (correct).
An agile approach is appropriate where the requirements are ill defined or subject to changing business circumstances. Requirements are expressed in collections of Stories and the main difference here is scope. A Story has very tightly defined scope and clear value. Stories are grouped into a collection we call an Epic with a single Theme e.g. Invoicing, Returns. Stories are also very similar to Use-cases.
Typically in a waterfall development the requirements are fixed and the two variables that flex are time or cost. In an agile approach we tightly fix the time-scale, called a Timebox or Sprint and flex the scope. We continually re-prioritise the stories to focus on highest value stories next. If a story is too big to be included in the Sprint, it is subject to the conventional techniques of functional decomposition and a separation of concerns.
Time-boxes allow the team, to regularly deliver a small piece of production quality of work for review by the product owner. These regular retrospectives also give the team an opportunity to review how they do things to look for improvements to working practices. Similar to Kaizen or continuous improvement in manufacturing.
Scrum is effective, but not easy, it will require significant changes in how you think, your processes and how you prioritise things. We call this transformation, in the maths sense, because we change the overall shape of the processes but do not remove any important pieces.
You can learn more about the actual how use Scrum at https://www.scrumalliance.org/
Some related and over lapping ideas:
Test/Feature/Behaviour driven development.
Lean Manufacturing and Just in Time deliver.
Continuous improvement.
anonymous said:
[redacted]
You are right, the main processes of Scrum are much simple than say RUP, SSADM and especially Prince, but some do struggle. Largely I think because resistance to change is strong in some people and summed up by the old adage "that's not how we do things here". They feel safe with the familiar.Flooble said:
If you think about it, the Apollo program was "Agile". They didn't just build a single Saturn V and fling three guys at the moon. Multiple missions, building and improving each time and learning the skills (in fact Gemini was used to develop several items, such as on-orbit rendezvous, which were needed for Apollo). So there's nothing new about it ...
https://www.ted.com/talks/tom_wujec_build_a_tower
AW111 said:
Having worked mainly in small or very small companies, I am a bit bemused by how a lot of stuff we have been doing for years has been formalised, packaged, and sold as new and revolutionary.
I agree this is not new, it is a return to and older heuristic approach to engineering. However it is a revolution of sorts, against management over reach. These approaches have emerged bottom up from developers with ideas and techniques appropriated from many fields by teams. The more recent move to formalisation and certification are necessary to overcome management resistance.4x4Tyke said:
In an agile approach we tightly fix the time-scale, called a Timebox or Sprint and flex the scope.
Small point, but it's not necessary to fix the timescale in agile. Scrum and XP do, Kanban has no such requirement (but doesn't forbid it either if you really want to).Personally I find scrum a bit too prescriptive for small teams on projects with a lifetime of less than a few months largely because the overheads of managing sprints are excessive until the team size and / or project duration increase.
Thanks for the replies.
I did some reading up and found these particularly useful:
http://www.scrumguides.org/
http://www.agile.org.uk/what-is-agile-working/
I had the interview on Friday and will know the result by end next week. It was about 50 mins of general questions including a few about Agile and Scrum.
Fingers crossed.
I did some reading up and found these particularly useful:
http://www.scrumguides.org/
http://www.agile.org.uk/what-is-agile-working/
I had the interview on Friday and will know the result by end next week. It was about 50 mins of general questions including a few about Agile and Scrum.
Fingers crossed.
Gassing Station | Jobs & Employment Matters | Top of Page | What's New | My Stuff