Last year I read an article on how Agile Development Must Be Driven from the Top.
For the last couple of months (approx. 9) I have been acting as Scrum Master, on the biggest project I've been involved in, and I have been battling this very thing. The overall project is being run in a classic waterfail (aka waterfall) approach and for some reason my colleagues and I thought we could convince our client that we could do our component of the project in an agile fashion. Boy were we wrong!
The project has shown all the classic symptoms of a classic waterfail project and as you could expect requirements were always hard to come by until certain "milestones" were reached. My thoughts were that shouldn't be a problem, we'll create user stories that cover the requirements that are known now and cover the gaps with extra stories later. In theory this should be fine, except for one tiny problem...
The agile approach we were using wasn't being driven from the top!
The project manager we were under, while he was happy for us to drive the agile approach, he and some of his own colleagues didn't truly understand the benefits of the metrics that can be derived from a well run agile methodology. He was too focused on sticking to his original plan - one massive development phase followed by a massive testing phase.
Where are things at now? I have gone back to development, the client has fallen back to complete waterfail approach. They are evening phasing out the end-to-end tests in favour of manually testing during the test phase.
So what did I learn from the experience? Unless management are TRULY willing to adopt the requirements of following an agile approach, don't waste your time.
Showing posts with label Scrum. Show all posts
Showing posts with label Scrum. Show all posts
Thursday, August 4, 2011
Friday, February 12, 2010
Great Scrum Resources
I just read a nice little post on Richard's Braindump regarding a new Professional Scrum Developer Course being offered at Scrum.org. Rather parrot what Richard said go read his post.
Anyway, while having a look through the site I came across some awesome Scrum Instructional Videos. Even if you've worked with Scrum, or maybe you think you've worked with Scrum, these are worth a look.
Enjoy!
Anyway, while having a look through the site I came across some awesome Scrum Instructional Videos. Even if you've worked with Scrum, or maybe you think you've worked with Scrum, these are worth a look.
Enjoy!
Tuesday, November 10, 2009
Poker - Planning Poker
Had my first game of Planning Poker not long ago. Even though I'd been working with Scrum for the last three years never had I performed planning of this type before. For those who are/ have been in a similar situation to myself you're probably asking, what they heck is this all about?
As the term poker suggests, there is a deck of cards involved, how ever this is no ordinary deck of cards. Each player has the following set of cards... ?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity.
So how does it work you may be asking?
Firstly we should explain when the game is played. This game is played when the project team is estimating the effort required for each of the user stories in the product backlog. But how do the numbers listed above work? You need to keep in mind that you are not trying to estimate the number of hours a user story is going to take, you are just giving an indication of how much effort you think is going to be required to complete the task in relation to the other tasks. The other major benefit of playing is that it generates discussion amongst the team.
Anyway rather then going on and on, read here: Planning Poker Estimating in Detail
Here's another very good read on Planning Poker - Agile Estimating
Hope this is helpful
As the term poker suggests, there is a deck of cards involved, how ever this is no ordinary deck of cards. Each player has the following set of cards... ?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity.
So how does it work you may be asking?
Firstly we should explain when the game is played. This game is played when the project team is estimating the effort required for each of the user stories in the product backlog. But how do the numbers listed above work? You need to keep in mind that you are not trying to estimate the number of hours a user story is going to take, you are just giving an indication of how much effort you think is going to be required to complete the task in relation to the other tasks. The other major benefit of playing is that it generates discussion amongst the team.
Anyway rather then going on and on, read here: Planning Poker Estimating in Detail
Here's another very good read on Planning Poker - Agile Estimating
Hope this is helpful
Wednesday, October 14, 2009
Agile Development - Made Easy
While I've developed in a Scrum environment for the last three years, I was never really exposed to the construction of the product backlog. Now though, I've recently started on a project in it's infancy stages and this is all changing.
The client practises Scrum actively and they go about creating the backlog by writing User Stories. User Stories? I'm thinking. What are they really?
Thankfully Google pointed me in the right direction => http://www.agile-software-development.com/.
Here you will find an awesome array of information on the Principles of Agile development, implementing Scrum, user stories, estimating within an agile environment, agile project management and a number of eBooks and presentations.
Enjoy!
The client practises Scrum actively and they go about creating the backlog by writing User Stories. User Stories? I'm thinking. What are they really?
Thankfully Google pointed me in the right direction => http://www.agile-software-development.com/.
Here you will find an awesome array of information on the Principles of Agile development, implementing Scrum, user stories, estimating within an agile environment, agile project management and a number of eBooks and presentations.
Enjoy!
Subscribe to:
Posts (Atom)